Livre IPv6 - User contributions [en]

MOOC:Bilan Session 7

2024-04-22T06:36:36Z

Panelli:

> [[MOOC:Accueil|MOOC]]>[[MOOC:Gestion_de_projet|Gestion de projet]]> Bilan Session 7

== Indicateurs session 7 ==

* Nombre d'inscrits : 4992
* Nombre d'actifs : 1068 (21.4% des inscrits )
* Nombre d'attestés :
* Nombre de badges délivrés :

MOOC:Bilan Session 7

2024-04-22T06:35:18Z

Panelli:

* Nombre d'inscrits : 4992
* Nombre d'actifs : 1068 (21.4% des inscrits )
* Nombre d'attestés :
* Nombre de badges délivrés :

MOOC:Bilan Session 7

2024-04-22T06:33:33Z

Panelli: Created page with "* Nombre d'inscrits : 3961 (session 7: 4992) * Nombre d'actifs : 731 (18.5% des inscrits, session 7: 21.4%) * Nombre d'attestés : 243 (6.1% des inscrits, 33.2% des actifs) *..."

* Nombre d'inscrits : 3961 (session 7: 4992)
* Nombre d'actifs : 731 (18.5% des inscrits, session 7: 21.4%)
* Nombre d'attestés : 243 (6.1% des inscrits, 33.2% des actifs)
* Nombre de badges délivrés : 217

MOOC:Gestion de projet

2024-04-22T06:32:19Z

Panelli: /* Session 7 (refonte) */

> [[MOOC:Accueil|MOOC]]>[[MOOC:Gestion_de_projet|Gestion de projet]]
----
= Sessions FUN=
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012/session01 Session 1 Trimestre 4 2015]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S02/session02/about Session 2 Trimestre 2 2016]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S03/session03/about Session 3 Trimestre 2 2017]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session04/about Session 4 Trimestre 2 2018]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/about Session 5 Trimestre 3 2019] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/about Session 6 Sesmestre 1 2021] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/about Session 7 Sesmestre 1 2022] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session07 Studio] et [https://www.fun-mooc.fr/fr/cours/objectif-ipv6/?edit présentation] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/fun/dashboard/ Tableau de bord du cours]
* [https://lms.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session08/info Session 8 Sesmestre 1 2023] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session08 Studio]
* [https://lms.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session09/info Session 9 Sesmestre 1 2024] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session09 Studio]

== Bilan ==
[https://docs.google.com/spreadsheets/d/1PUOKsLGiOqckVbqWy1jh4ZoixsOUtKyit13ypD8x0us/edit?usp=sharing Audiences des différentes sessions]

= Documents de travail =

== Session 8 ==
* [[MOOC:Corrections s8|Corrections pour la session 8]]
* [[MOOC:Bilan Session 8|Bilan Session 8]]

== Session 7 (refonte) ==

==== Actions ====
* [[MOOC:Plan_decouverte| Plan du cours : découverte]]
* [https://miro.com/app/board/o9J_lYdjJSw=/ Tableau blanc des ateliers] (Miro)
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Taches Session 7| Liste des tâches]]
* [[MOOC:Table des corrections7|Table des corrections]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=263830683 Méta et scénarisation du cours sur FUN]

* [[MOOC:Bilan Session 7|Bilan Session 7]]

==== Comptes rendus ====

* [[MOOC:Réunion_20220121|20220121 Réunion coordination Session 7]]
* [[MOOC:Réunion_20210707|20210707 Réunion Avancement]]
* [[MOOC:Réunion_20210618|20210618 Réunion Bilan Session 6]]
* [[MOOC:Réunion_20210531|20210531 Atelier 6 : Refonte Compagnon et Seq1]]
* [[MOOC:Réunion_20210520|20210520 Atelier 5 : Renommage activités et Seq3]]
* [[MOOC:Réunion_20210503|20210503 Atelier 4 : Plan découverte et Seq4]]
* [[MOOC:Réunion_20210426|20210426 Atelier 3 : Evolution Découverte]]
* [[MOOC:Réunion_20210401|20210401 Atelier 2 : Plan découverte]]
* [[MOOC:Réunion_20210315|20210315 Atelier 1 : Structuration]]

== Guides et Aides ==
* [[MOOC:Guide de rédaction|Guide de rédaction]]
* [[MOOC:Guide de tournage|Guide de tournage]]
* [[MOOC:Guide des quizz|Guide des quizz]]
* [[MOOC:Ouverture de séquence|Guide de l'ouverture de session]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=480308602 Méta et scénarisation du cours sur FUN]

=== Informations ===
* Objectifs pédagogiques: [http://fr.wikipedia.org/wiki/Taxonomie_de_Bloom taxonomie de Bloom] (limiter aux niveaux 1, 2 voir 3)
* [[MOOC:Stats Compagnon| Statistiques sur le document compagnon]]

= Outils =
* [http://wiki.g6.asso.fr/index.php?title=Annuaire_Intervenants_MOOC Annuaire Intervenants MOOC]
* [https://docs.google.com/spreadsheets/d/1xwPM_2cbo_Fw9iTS14YyU2VpbufOT0v8NVUMRgp1I9Q/edit?usp=sharing Annuaire] (nouveau)
* Liste de diffusion [mailto:mooc-ipv6@imt-atlantique.fr mooc ipv6]
** La page d'accueil de la liste : https://listes.imt-atlantique.fr/wws/info/mooc-ipv6
** Introduction aux listes de diffusion : https://listes.imt-atlantique.fr/wws/help/introduction
* [[MOOC:Lille| Séjour à IMT Lille]]
* [http://livre.g6.asso.fr/index.php?title=Special:Search&fulltext=Search&profile=advanced Recherche sur le Wiki]
* [https://docs.google.com/document/d/1A72NHGB17awkHqUOrm-KFAjbiMb3dUdV3v-z0tRB7lA/edit Le Tableau blanc]
* [https://us04web.zoom.us/j/9708780848 Session ZOOM ]

= Archive comptes rendus de réunions =
* [[MOOC:Réunion_20201118|20201118 Point d'avancement]]
* [[MOOC:Réunion_20200615|20200615 Réunion pédago]]
* [[MOOC:Réunion_20200527|20200527 Point d'avancement]]
* [[MOOC:Réunion_20200402|20200402 Réunion pédago]]
* [[MOOC:Réunion_20200306|20200306 Réunion fin de rédaction]]
* [[MOOC:Réunion_20200212|20200212 Réunion refonte session6 2]]
* [[MOOC:Réunion_20200121|20200121 Réunion refonte session6]]
* [[MOOC:Réunion_20190927|20190927 Réunion bilan session5]]
* [[MOOC:Réunion_20190319|20190319 Réunion session5]]
* [[MOOC:Réunion_20181019|20181019 Réunion refonte]]
* [[MOOC:Réunion_20180709|20180709 Réunion bilan session 4]]
* [[MOOC:Réunion_20170306|20170306 Réunion d'avancement session3]]
* [https://docs.google.com/document/d/1hjqUmFv2WvJfgRcuBQS0mXItJRGAYqpearu2qFvCxG4/edit#heading=h.5ajsmpmo8nls 20161128 Réunion de reprise de contact]
* [https://docs.google.com/document/d/1dQn_fgq3Z8UTpW1pZ647lCisXwpU_6c-_Q0jFqNEjT8/edit#heading=h.7e8c433picx9 20160616 Réunion bilan session2]
* [[MOOC:Réunion_20160414|20160414 Réunion d'avancement2]]
* [[MOOC:Réunion_20160401|20160401 Réunion d'avancement1]]
* [[MOOC:Réunion 20160209|20160209 Réunion avant session 2]]
* [[MOOC:Réunion 20151207|20151207 Réunion bilan session1]]
* [[MOOC:Réunion 20151006|20151006 Réunion finalisation]]
* [[MOOC:Réunion 20150904|20150904 Réunion d'avancement]]
* [[MOOC:Réunion 20150311|20150311 Réunion de synchronisation]]
* [[MOOC:Réunion 20150306|20150306 Réunion d'avancement]]
* [[MOOC:Réunion 20150216|20150216 Réunion d'avancement]]
* [[MOOC:Réunion 20150203|20150203 Réunion d'avancement]]
* [[MOOC:Réunion 20150115|20150115 Réunion d'avancement]]
* [[MOOC:Réunion 20141211|20141211 Rencontre MOOC Paris]]
* [[MOOC:Réunion 20141201|20141201 Réunion d'avancement]]
* [[MOOC:Réunion 20141124|20141124 Réunion Articulation PRD/IPv6]]
* [[MOOC:Réunion 20141031|20141031 Réunion de démarrage]]

= Archives =

== Session 6 ==

==== Actions ====

* [[MOOC:Evolutions | Syllabus session 6]]
* [[MOOC:Taches Session 6| Liste des tâches]]
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Table des corrections6|Table des corrections]]

* [[MOOC:Bilan Session 6|Bilan Session 6]]

===== Animation =====

* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/ Cours en ligne]
** [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session06 Studio]
* [[MOOC:Cahier des corrections|Cahier des corrections]]

== Session 5 ==
* [[MOOC:Session_5-Taches| Liste des tâches]]
* [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session05 Studio]
* [[MOOC:Bilan_Session5|Bilan Session 5]]
* [[MOOC:Manuel_Apprenant_Session5|archive manuel apprenant session5]]

== Session 4 ==
* [[MOOC:Bilan_Session_4]]

== Session 3 ==
* [[MOOC:Taches_Session_3]]
* [[MOOC:Matrice relecture Compagnon]]
* [[MOOC:Matrice des Quiz]]
* [[MOOC:Session3-Alignement Evaluations| Alignement Evaluations]]
* [[MOOC:Bilan_Session_3]]
* [[MOOC:Erratum_Session_3]]

=== Session 2===
* [[MOOC:Taches Session 2]]
* [[MOOC:Corrections des videos]]

=== Session 1===
* [[MOOC:Formalisation de la structure]]
* [[MOOC:Figures]]
* [[MOOC:Matrice des séquences]]
* [[MOOC:Matrice des auteurs]]
* [[MOOC:Bilan Session1]]
* [[MOOC:Cahier_des_Charges_Plateforme_Lab|Cahier des charges de la plateforme Lab]]

=Communication=
* Page d'annonce du MOOC IPv6 sur FUN : [https://www.france-universite-numerique-mooc.fr/courses/MinesTelecom/04012/session01/about Objectif IPv6 : vers l'internet nouvelle génération]
* Annonces faites par l'Université de la Réunion:
** [[MOOC:comUR | Message du 15 juillet]]
** Sur le site institutionnel : [http://www.univ-reunion.fr/actualites/ipv6-le-premier-mooc-de-luniversite-de-la-reunion/ Actualités]

* Presentation du plan: https://prezi.com/jjmq_45fjhfr/mooc-objectif-ipv6-plan-du-cours/

* Pour les avis mymooc https://www.my-mooc.com/fr/mooc/objectif-ipv6-vers-linternet-nouvelle-generation/

MOOC:Gestion de projet

2024-04-22T06:31:54Z

Panelli: /* Session 7 (refonte) */

> [[MOOC:Accueil|MOOC]]>[[MOOC:Gestion_de_projet|Gestion de projet]]
----
= Sessions FUN=
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012/session01 Session 1 Trimestre 4 2015]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S02/session02/about Session 2 Trimestre 2 2016]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S03/session03/about Session 3 Trimestre 2 2017]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session04/about Session 4 Trimestre 2 2018]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/about Session 5 Trimestre 3 2019] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/about Session 6 Sesmestre 1 2021] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/about Session 7 Sesmestre 1 2022] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session07 Studio] et [https://www.fun-mooc.fr/fr/cours/objectif-ipv6/?edit présentation] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/fun/dashboard/ Tableau de bord du cours]
* [https://lms.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session08/info Session 8 Sesmestre 1 2023] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session08 Studio]
* [https://lms.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session09/info Session 9 Sesmestre 1 2024] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session09 Studio]

== Bilan ==
[https://docs.google.com/spreadsheets/d/1PUOKsLGiOqckVbqWy1jh4ZoixsOUtKyit13ypD8x0us/edit?usp=sharing Audiences des différentes sessions]

= Documents de travail =

== Session 8 ==
* [[MOOC:Corrections s8|Corrections pour la session 8]]
* [[MOOC:Bilan Session 8|Bilan Session 8]]

== Session 7 (refonte) ==

==== Actions ====
* [[MOOC:Plan_decouverte| Plan du cours : découverte]]
* [https://miro.com/app/board/o9J_lYdjJSw=/ Tableau blanc des ateliers] (Miro)
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Taches Session 7| Liste des tâches]]
* [[MOOC:Table des corrections7|Table des corrections]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=263830683 Méta et scénarisation du cours sur FUN]

==== Comptes rendus ====

* [[MOOC:Réunion_20220121|20220121 Réunion coordination Session 7]]
* [[MOOC:Réunion_20210707|20210707 Réunion Avancement]]
* [[MOOC:Réunion_20210618|20210618 Réunion Bilan Session 6]]
* [[MOOC:Réunion_20210531|20210531 Atelier 6 : Refonte Compagnon et Seq1]]
* [[MOOC:Réunion_20210520|20210520 Atelier 5 : Renommage activités et Seq3]]
* [[MOOC:Réunion_20210503|20210503 Atelier 4 : Plan découverte et Seq4]]
* [[MOOC:Réunion_20210426|20210426 Atelier 3 : Evolution Découverte]]
* [[MOOC:Réunion_20210401|20210401 Atelier 2 : Plan découverte]]
* [[MOOC:Réunion_20210315|20210315 Atelier 1 : Structuration]]

* [[MOOC:Bilan Session 7|Bilan Session 7]]

== Guides et Aides ==
* [[MOOC:Guide de rédaction|Guide de rédaction]]
* [[MOOC:Guide de tournage|Guide de tournage]]
* [[MOOC:Guide des quizz|Guide des quizz]]
* [[MOOC:Ouverture de séquence|Guide de l'ouverture de session]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=480308602 Méta et scénarisation du cours sur FUN]

=== Informations ===
* Objectifs pédagogiques: [http://fr.wikipedia.org/wiki/Taxonomie_de_Bloom taxonomie de Bloom] (limiter aux niveaux 1, 2 voir 3)
* [[MOOC:Stats Compagnon| Statistiques sur le document compagnon]]

= Outils =
* [http://wiki.g6.asso.fr/index.php?title=Annuaire_Intervenants_MOOC Annuaire Intervenants MOOC]
* [https://docs.google.com/spreadsheets/d/1xwPM_2cbo_Fw9iTS14YyU2VpbufOT0v8NVUMRgp1I9Q/edit?usp=sharing Annuaire] (nouveau)
* Liste de diffusion [mailto:mooc-ipv6@imt-atlantique.fr mooc ipv6]
** La page d'accueil de la liste : https://listes.imt-atlantique.fr/wws/info/mooc-ipv6
** Introduction aux listes de diffusion : https://listes.imt-atlantique.fr/wws/help/introduction
* [[MOOC:Lille| Séjour à IMT Lille]]
* [http://livre.g6.asso.fr/index.php?title=Special:Search&fulltext=Search&profile=advanced Recherche sur le Wiki]
* [https://docs.google.com/document/d/1A72NHGB17awkHqUOrm-KFAjbiMb3dUdV3v-z0tRB7lA/edit Le Tableau blanc]
* [https://us04web.zoom.us/j/9708780848 Session ZOOM ]

= Archive comptes rendus de réunions =
* [[MOOC:Réunion_20201118|20201118 Point d'avancement]]
* [[MOOC:Réunion_20200615|20200615 Réunion pédago]]
* [[MOOC:Réunion_20200527|20200527 Point d'avancement]]
* [[MOOC:Réunion_20200402|20200402 Réunion pédago]]
* [[MOOC:Réunion_20200306|20200306 Réunion fin de rédaction]]
* [[MOOC:Réunion_20200212|20200212 Réunion refonte session6 2]]
* [[MOOC:Réunion_20200121|20200121 Réunion refonte session6]]
* [[MOOC:Réunion_20190927|20190927 Réunion bilan session5]]
* [[MOOC:Réunion_20190319|20190319 Réunion session5]]
* [[MOOC:Réunion_20181019|20181019 Réunion refonte]]
* [[MOOC:Réunion_20180709|20180709 Réunion bilan session 4]]
* [[MOOC:Réunion_20170306|20170306 Réunion d'avancement session3]]
* [https://docs.google.com/document/d/1hjqUmFv2WvJfgRcuBQS0mXItJRGAYqpearu2qFvCxG4/edit#heading=h.5ajsmpmo8nls 20161128 Réunion de reprise de contact]
* [https://docs.google.com/document/d/1dQn_fgq3Z8UTpW1pZ647lCisXwpU_6c-_Q0jFqNEjT8/edit#heading=h.7e8c433picx9 20160616 Réunion bilan session2]
* [[MOOC:Réunion_20160414|20160414 Réunion d'avancement2]]
* [[MOOC:Réunion_20160401|20160401 Réunion d'avancement1]]
* [[MOOC:Réunion 20160209|20160209 Réunion avant session 2]]
* [[MOOC:Réunion 20151207|20151207 Réunion bilan session1]]
* [[MOOC:Réunion 20151006|20151006 Réunion finalisation]]
* [[MOOC:Réunion 20150904|20150904 Réunion d'avancement]]
* [[MOOC:Réunion 20150311|20150311 Réunion de synchronisation]]
* [[MOOC:Réunion 20150306|20150306 Réunion d'avancement]]
* [[MOOC:Réunion 20150216|20150216 Réunion d'avancement]]
* [[MOOC:Réunion 20150203|20150203 Réunion d'avancement]]
* [[MOOC:Réunion 20150115|20150115 Réunion d'avancement]]
* [[MOOC:Réunion 20141211|20141211 Rencontre MOOC Paris]]
* [[MOOC:Réunion 20141201|20141201 Réunion d'avancement]]
* [[MOOC:Réunion 20141124|20141124 Réunion Articulation PRD/IPv6]]
* [[MOOC:Réunion 20141031|20141031 Réunion de démarrage]]

= Archives =

== Session 6 ==

==== Actions ====

* [[MOOC:Evolutions | Syllabus session 6]]
* [[MOOC:Taches Session 6| Liste des tâches]]
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Table des corrections6|Table des corrections]]

* [[MOOC:Bilan Session 6|Bilan Session 6]]

===== Animation =====

* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/ Cours en ligne]
** [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session06 Studio]
* [[MOOC:Cahier des corrections|Cahier des corrections]]

== Session 5 ==
* [[MOOC:Session_5-Taches| Liste des tâches]]
* [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session05 Studio]
* [[MOOC:Bilan_Session5|Bilan Session 5]]
* [[MOOC:Manuel_Apprenant_Session5|archive manuel apprenant session5]]

== Session 4 ==
* [[MOOC:Bilan_Session_4]]

== Session 3 ==
* [[MOOC:Taches_Session_3]]
* [[MOOC:Matrice relecture Compagnon]]
* [[MOOC:Matrice des Quiz]]
* [[MOOC:Session3-Alignement Evaluations| Alignement Evaluations]]
* [[MOOC:Bilan_Session_3]]
* [[MOOC:Erratum_Session_3]]

=== Session 2===
* [[MOOC:Taches Session 2]]
* [[MOOC:Corrections des videos]]

=== Session 1===
* [[MOOC:Formalisation de la structure]]
* [[MOOC:Figures]]
* [[MOOC:Matrice des séquences]]
* [[MOOC:Matrice des auteurs]]
* [[MOOC:Bilan Session1]]
* [[MOOC:Cahier_des_Charges_Plateforme_Lab|Cahier des charges de la plateforme Lab]]

=Communication=
* Page d'annonce du MOOC IPv6 sur FUN : [https://www.france-universite-numerique-mooc.fr/courses/MinesTelecom/04012/session01/about Objectif IPv6 : vers l'internet nouvelle génération]
* Annonces faites par l'Université de la Réunion:
** [[MOOC:comUR | Message du 15 juillet]]
** Sur le site institutionnel : [http://www.univ-reunion.fr/actualites/ipv6-le-premier-mooc-de-luniversite-de-la-reunion/ Actualités]

* Presentation du plan: https://prezi.com/jjmq_45fjhfr/mooc-objectif-ipv6-plan-du-cours/

* Pour les avis mymooc https://www.my-mooc.com/fr/mooc/objectif-ipv6-vers-linternet-nouvelle-generation/

MOOC:Gestion de projet

2024-03-22T10:46:34Z

Panelli: /* Sessions FUN */

> [[MOOC:Accueil|MOOC]]>[[MOOC:Gestion_de_projet|Gestion de projet]]
----
= Sessions FUN=
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012/session01 Session 1 Trimestre 4 2015]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S02/session02/about Session 2 Trimestre 2 2016]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S03/session03/about Session 3 Trimestre 2 2017]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session04/about Session 4 Trimestre 2 2018]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/about Session 5 Trimestre 3 2019] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/about Session 6 Sesmestre 1 2021] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/about Session 7 Sesmestre 1 2022] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session07 Studio] et [https://www.fun-mooc.fr/fr/cours/objectif-ipv6/?edit présentation] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/fun/dashboard/ Tableau de bord du cours]
* [https://lms.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session08/info Session 8 Sesmestre 1 2023] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session08 Studio]
* [https://lms.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session09/info Session 9 Sesmestre 1 2024] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session09 Studio]

== Bilan ==
[https://docs.google.com/spreadsheets/d/1PUOKsLGiOqckVbqWy1jh4ZoixsOUtKyit13ypD8x0us/edit?usp=sharing Audiences des différentes sessions]

= Documents de travail =

== Session 8 ==
* [[MOOC:Corrections s8|Corrections pour la session 8]]
* [[MOOC:Bilan Session 8|Bilan Session 8]]

== Session 7 (refonte) ==

==== Actions ====
* [[MOOC:Plan_decouverte| Plan du cours : découverte]]
* [https://miro.com/app/board/o9J_lYdjJSw=/ Tableau blanc des ateliers] (Miro)
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Taches Session 7| Liste des tâches]]
* [[MOOC:Table des corrections7|Table des corrections]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=263830683 Méta et scénarisation du cours sur FUN]

==== Comptes rendus ====

* [[MOOC:Réunion_20220121|20220121 Réunion coordination Session 7]]
* [[MOOC:Réunion_20210707|20210707 Réunion Avancement]]
* [[MOOC:Réunion_20210618|20210618 Réunion Bilan Session 6]]
* [[MOOC:Réunion_20210531|20210531 Atelier 6 : Refonte Compagnon et Seq1]]
* [[MOOC:Réunion_20210520|20210520 Atelier 5 : Renommage activités et Seq3]]
* [[MOOC:Réunion_20210503|20210503 Atelier 4 : Plan découverte et Seq4]]
* [[MOOC:Réunion_20210426|20210426 Atelier 3 : Evolution Découverte]]
* [[MOOC:Réunion_20210401|20210401 Atelier 2 : Plan découverte]]
* [[MOOC:Réunion_20210315|20210315 Atelier 1 : Structuration]]

== Guides et Aides ==
* [[MOOC:Guide de rédaction|Guide de rédaction]]
* [[MOOC:Guide de tournage|Guide de tournage]]
* [[MOOC:Guide des quizz|Guide des quizz]]
* [[MOOC:Ouverture de séquence|Guide de l'ouverture de session]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=480308602 Méta et scénarisation du cours sur FUN]

=== Informations ===
* Objectifs pédagogiques: [http://fr.wikipedia.org/wiki/Taxonomie_de_Bloom taxonomie de Bloom] (limiter aux niveaux 1, 2 voir 3)
* [[MOOC:Stats Compagnon| Statistiques sur le document compagnon]]

= Outils =
* [http://wiki.g6.asso.fr/index.php?title=Annuaire_Intervenants_MOOC Annuaire Intervenants MOOC]
* [https://docs.google.com/spreadsheets/d/1xwPM_2cbo_Fw9iTS14YyU2VpbufOT0v8NVUMRgp1I9Q/edit?usp=sharing Annuaire] (nouveau)
* Liste de diffusion [mailto:mooc-ipv6@imt-atlantique.fr mooc ipv6]
** La page d'accueil de la liste : https://listes.imt-atlantique.fr/wws/info/mooc-ipv6
** Introduction aux listes de diffusion : https://listes.imt-atlantique.fr/wws/help/introduction
* [[MOOC:Lille| Séjour à IMT Lille]]
* [http://livre.g6.asso.fr/index.php?title=Special:Search&fulltext=Search&profile=advanced Recherche sur le Wiki]
* [https://docs.google.com/document/d/1A72NHGB17awkHqUOrm-KFAjbiMb3dUdV3v-z0tRB7lA/edit Le Tableau blanc]
* [https://us04web.zoom.us/j/9708780848 Session ZOOM ]

= Archive comptes rendus de réunions =
* [[MOOC:Réunion_20201118|20201118 Point d'avancement]]
* [[MOOC:Réunion_20200615|20200615 Réunion pédago]]
* [[MOOC:Réunion_20200527|20200527 Point d'avancement]]
* [[MOOC:Réunion_20200402|20200402 Réunion pédago]]
* [[MOOC:Réunion_20200306|20200306 Réunion fin de rédaction]]
* [[MOOC:Réunion_20200212|20200212 Réunion refonte session6 2]]
* [[MOOC:Réunion_20200121|20200121 Réunion refonte session6]]
* [[MOOC:Réunion_20190927|20190927 Réunion bilan session5]]
* [[MOOC:Réunion_20190319|20190319 Réunion session5]]
* [[MOOC:Réunion_20181019|20181019 Réunion refonte]]
* [[MOOC:Réunion_20180709|20180709 Réunion bilan session 4]]
* [[MOOC:Réunion_20170306|20170306 Réunion d'avancement session3]]
* [https://docs.google.com/document/d/1hjqUmFv2WvJfgRcuBQS0mXItJRGAYqpearu2qFvCxG4/edit#heading=h.5ajsmpmo8nls 20161128 Réunion de reprise de contact]
* [https://docs.google.com/document/d/1dQn_fgq3Z8UTpW1pZ647lCisXwpU_6c-_Q0jFqNEjT8/edit#heading=h.7e8c433picx9 20160616 Réunion bilan session2]
* [[MOOC:Réunion_20160414|20160414 Réunion d'avancement2]]
* [[MOOC:Réunion_20160401|20160401 Réunion d'avancement1]]
* [[MOOC:Réunion 20160209|20160209 Réunion avant session 2]]
* [[MOOC:Réunion 20151207|20151207 Réunion bilan session1]]
* [[MOOC:Réunion 20151006|20151006 Réunion finalisation]]
* [[MOOC:Réunion 20150904|20150904 Réunion d'avancement]]
* [[MOOC:Réunion 20150311|20150311 Réunion de synchronisation]]
* [[MOOC:Réunion 20150306|20150306 Réunion d'avancement]]
* [[MOOC:Réunion 20150216|20150216 Réunion d'avancement]]
* [[MOOC:Réunion 20150203|20150203 Réunion d'avancement]]
* [[MOOC:Réunion 20150115|20150115 Réunion d'avancement]]
* [[MOOC:Réunion 20141211|20141211 Rencontre MOOC Paris]]
* [[MOOC:Réunion 20141201|20141201 Réunion d'avancement]]
* [[MOOC:Réunion 20141124|20141124 Réunion Articulation PRD/IPv6]]
* [[MOOC:Réunion 20141031|20141031 Réunion de démarrage]]

= Archives =

== Session 6 ==

==== Actions ====

* [[MOOC:Evolutions | Syllabus session 6]]
* [[MOOC:Taches Session 6| Liste des tâches]]
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Table des corrections6|Table des corrections]]

* [[MOOC:Bilan Session 6|Bilan Session 6]]

===== Animation =====

* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/ Cours en ligne]
** [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session06 Studio]
* [[MOOC:Cahier des corrections|Cahier des corrections]]

== Session 5 ==
* [[MOOC:Session_5-Taches| Liste des tâches]]
* [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session05 Studio]
* [[MOOC:Bilan_Session5|Bilan Session 5]]
* [[MOOC:Manuel_Apprenant_Session5|archive manuel apprenant session5]]

== Session 4 ==
* [[MOOC:Bilan_Session_4]]

== Session 3 ==
* [[MOOC:Taches_Session_3]]
* [[MOOC:Matrice relecture Compagnon]]
* [[MOOC:Matrice des Quiz]]
* [[MOOC:Session3-Alignement Evaluations| Alignement Evaluations]]
* [[MOOC:Bilan_Session_3]]
* [[MOOC:Erratum_Session_3]]

=== Session 2===
* [[MOOC:Taches Session 2]]
* [[MOOC:Corrections des videos]]

=== Session 1===
* [[MOOC:Formalisation de la structure]]
* [[MOOC:Figures]]
* [[MOOC:Matrice des séquences]]
* [[MOOC:Matrice des auteurs]]
* [[MOOC:Bilan Session1]]
* [[MOOC:Cahier_des_Charges_Plateforme_Lab|Cahier des charges de la plateforme Lab]]

=Communication=
* Page d'annonce du MOOC IPv6 sur FUN : [https://www.france-universite-numerique-mooc.fr/courses/MinesTelecom/04012/session01/about Objectif IPv6 : vers l'internet nouvelle génération]
* Annonces faites par l'Université de la Réunion:
** [[MOOC:comUR | Message du 15 juillet]]
** Sur le site institutionnel : [http://www.univ-reunion.fr/actualites/ipv6-le-premier-mooc-de-luniversite-de-la-reunion/ Actualités]

* Presentation du plan: https://prezi.com/jjmq_45fjhfr/mooc-objectif-ipv6-plan-du-cours/

* Pour les avis mymooc https://www.my-mooc.com/fr/mooc/objectif-ipv6-vers-linternet-nouvelle-generation/

MOOC:Gestion de projet

2024-03-22T10:45:43Z

Panelli: /* Sessions FUN */

> [[MOOC:Accueil|MOOC]]>[[MOOC:Gestion_de_projet|Gestion de projet]]
----
= Sessions FUN=
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012/session01 Session 1 Trimestre 4 2015]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S02/session02/about Session 2 Trimestre 2 2016]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S03/session03/about Session 3 Trimestre 2 2017]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session04/about Session 4 Trimestre 2 2018]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/about Session 5 Trimestre 3 2019] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/about Session 6 Sesmestre 1 2021] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/about Session 7 Sesmestre 1 2022] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session07 Studio] et [https://www.fun-mooc.fr/fr/cours/objectif-ipv6/?edit présentation] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session08/about Session 8 Sesmestre 1 2023] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session08 Studio]
* [https://lms.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session09/info Session 9 Sesmestre 1 2024] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session09 Studio]

== Bilan ==
[https://docs.google.com/spreadsheets/d/1PUOKsLGiOqckVbqWy1jh4ZoixsOUtKyit13ypD8x0us/edit?usp=sharing Audiences des différentes sessions]

= Documents de travail =

== Session 8 ==
* [[MOOC:Corrections s8|Corrections pour la session 8]]
* [[MOOC:Bilan Session 8|Bilan Session 8]]

== Session 7 (refonte) ==

==== Actions ====
* [[MOOC:Plan_decouverte| Plan du cours : découverte]]
* [https://miro.com/app/board/o9J_lYdjJSw=/ Tableau blanc des ateliers] (Miro)
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Taches Session 7| Liste des tâches]]
* [[MOOC:Table des corrections7|Table des corrections]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=263830683 Méta et scénarisation du cours sur FUN]

==== Comptes rendus ====

* [[MOOC:Réunion_20220121|20220121 Réunion coordination Session 7]]
* [[MOOC:Réunion_20210707|20210707 Réunion Avancement]]
* [[MOOC:Réunion_20210618|20210618 Réunion Bilan Session 6]]
* [[MOOC:Réunion_20210531|20210531 Atelier 6 : Refonte Compagnon et Seq1]]
* [[MOOC:Réunion_20210520|20210520 Atelier 5 : Renommage activités et Seq3]]
* [[MOOC:Réunion_20210503|20210503 Atelier 4 : Plan découverte et Seq4]]
* [[MOOC:Réunion_20210426|20210426 Atelier 3 : Evolution Découverte]]
* [[MOOC:Réunion_20210401|20210401 Atelier 2 : Plan découverte]]
* [[MOOC:Réunion_20210315|20210315 Atelier 1 : Structuration]]

== Guides et Aides ==
* [[MOOC:Guide de rédaction|Guide de rédaction]]
* [[MOOC:Guide de tournage|Guide de tournage]]
* [[MOOC:Guide des quizz|Guide des quizz]]
* [[MOOC:Ouverture de séquence|Guide de l'ouverture de session]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=480308602 Méta et scénarisation du cours sur FUN]

=== Informations ===
* Objectifs pédagogiques: [http://fr.wikipedia.org/wiki/Taxonomie_de_Bloom taxonomie de Bloom] (limiter aux niveaux 1, 2 voir 3)
* [[MOOC:Stats Compagnon| Statistiques sur le document compagnon]]

= Outils =
* [http://wiki.g6.asso.fr/index.php?title=Annuaire_Intervenants_MOOC Annuaire Intervenants MOOC]
* [https://docs.google.com/spreadsheets/d/1xwPM_2cbo_Fw9iTS14YyU2VpbufOT0v8NVUMRgp1I9Q/edit?usp=sharing Annuaire] (nouveau)
* Liste de diffusion [mailto:mooc-ipv6@imt-atlantique.fr mooc ipv6]
** La page d'accueil de la liste : https://listes.imt-atlantique.fr/wws/info/mooc-ipv6
** Introduction aux listes de diffusion : https://listes.imt-atlantique.fr/wws/help/introduction
* [[MOOC:Lille| Séjour à IMT Lille]]
* [http://livre.g6.asso.fr/index.php?title=Special:Search&fulltext=Search&profile=advanced Recherche sur le Wiki]
* [https://docs.google.com/document/d/1A72NHGB17awkHqUOrm-KFAjbiMb3dUdV3v-z0tRB7lA/edit Le Tableau blanc]
* [https://us04web.zoom.us/j/9708780848 Session ZOOM ]

= Archive comptes rendus de réunions =
* [[MOOC:Réunion_20201118|20201118 Point d'avancement]]
* [[MOOC:Réunion_20200615|20200615 Réunion pédago]]
* [[MOOC:Réunion_20200527|20200527 Point d'avancement]]
* [[MOOC:Réunion_20200402|20200402 Réunion pédago]]
* [[MOOC:Réunion_20200306|20200306 Réunion fin de rédaction]]
* [[MOOC:Réunion_20200212|20200212 Réunion refonte session6 2]]
* [[MOOC:Réunion_20200121|20200121 Réunion refonte session6]]
* [[MOOC:Réunion_20190927|20190927 Réunion bilan session5]]
* [[MOOC:Réunion_20190319|20190319 Réunion session5]]
* [[MOOC:Réunion_20181019|20181019 Réunion refonte]]
* [[MOOC:Réunion_20180709|20180709 Réunion bilan session 4]]
* [[MOOC:Réunion_20170306|20170306 Réunion d'avancement session3]]
* [https://docs.google.com/document/d/1hjqUmFv2WvJfgRcuBQS0mXItJRGAYqpearu2qFvCxG4/edit#heading=h.5ajsmpmo8nls 20161128 Réunion de reprise de contact]
* [https://docs.google.com/document/d/1dQn_fgq3Z8UTpW1pZ647lCisXwpU_6c-_Q0jFqNEjT8/edit#heading=h.7e8c433picx9 20160616 Réunion bilan session2]
* [[MOOC:Réunion_20160414|20160414 Réunion d'avancement2]]
* [[MOOC:Réunion_20160401|20160401 Réunion d'avancement1]]
* [[MOOC:Réunion 20160209|20160209 Réunion avant session 2]]
* [[MOOC:Réunion 20151207|20151207 Réunion bilan session1]]
* [[MOOC:Réunion 20151006|20151006 Réunion finalisation]]
* [[MOOC:Réunion 20150904|20150904 Réunion d'avancement]]
* [[MOOC:Réunion 20150311|20150311 Réunion de synchronisation]]
* [[MOOC:Réunion 20150306|20150306 Réunion d'avancement]]
* [[MOOC:Réunion 20150216|20150216 Réunion d'avancement]]
* [[MOOC:Réunion 20150203|20150203 Réunion d'avancement]]
* [[MOOC:Réunion 20150115|20150115 Réunion d'avancement]]
* [[MOOC:Réunion 20141211|20141211 Rencontre MOOC Paris]]
* [[MOOC:Réunion 20141201|20141201 Réunion d'avancement]]
* [[MOOC:Réunion 20141124|20141124 Réunion Articulation PRD/IPv6]]
* [[MOOC:Réunion 20141031|20141031 Réunion de démarrage]]

= Archives =

== Session 6 ==

==== Actions ====

* [[MOOC:Evolutions | Syllabus session 6]]
* [[MOOC:Taches Session 6| Liste des tâches]]
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Table des corrections6|Table des corrections]]

* [[MOOC:Bilan Session 6|Bilan Session 6]]

===== Animation =====

* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/ Cours en ligne]
** [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session06 Studio]
* [[MOOC:Cahier des corrections|Cahier des corrections]]

== Session 5 ==
* [[MOOC:Session_5-Taches| Liste des tâches]]
* [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session05 Studio]
* [[MOOC:Bilan_Session5|Bilan Session 5]]
* [[MOOC:Manuel_Apprenant_Session5|archive manuel apprenant session5]]

== Session 4 ==
* [[MOOC:Bilan_Session_4]]

== Session 3 ==
* [[MOOC:Taches_Session_3]]
* [[MOOC:Matrice relecture Compagnon]]
* [[MOOC:Matrice des Quiz]]
* [[MOOC:Session3-Alignement Evaluations| Alignement Evaluations]]
* [[MOOC:Bilan_Session_3]]
* [[MOOC:Erratum_Session_3]]

=== Session 2===
* [[MOOC:Taches Session 2]]
* [[MOOC:Corrections des videos]]

=== Session 1===
* [[MOOC:Formalisation de la structure]]
* [[MOOC:Figures]]
* [[MOOC:Matrice des séquences]]
* [[MOOC:Matrice des auteurs]]
* [[MOOC:Bilan Session1]]
* [[MOOC:Cahier_des_Charges_Plateforme_Lab|Cahier des charges de la plateforme Lab]]

=Communication=
* Page d'annonce du MOOC IPv6 sur FUN : [https://www.france-universite-numerique-mooc.fr/courses/MinesTelecom/04012/session01/about Objectif IPv6 : vers l'internet nouvelle génération]
* Annonces faites par l'Université de la Réunion:
** [[MOOC:comUR | Message du 15 juillet]]
** Sur le site institutionnel : [http://www.univ-reunion.fr/actualites/ipv6-le-premier-mooc-de-luniversite-de-la-reunion/ Actualités]

* Presentation du plan: https://prezi.com/jjmq_45fjhfr/mooc-objectif-ipv6-plan-du-cours/

* Pour les avis mymooc https://www.my-mooc.com/fr/mooc/objectif-ipv6-vers-linternet-nouvelle-generation/

MOOC:Gestion de projet

2024-03-22T10:44:05Z

Panelli: /* Sessions FUN */

> [[MOOC:Accueil|MOOC]]>[[MOOC:Gestion_de_projet|Gestion de projet]]
----
= Sessions FUN=
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012/session01 Session 1 Trimestre 4 2015]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S02/session02/about Session 2 Trimestre 2 2016]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S03/session03/about Session 3 Trimestre 2 2017]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session04/about Session 4 Trimestre 2 2018]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/about Session 5 Trimestre 3 2019] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/about Session 6 Sesmestre 1 2021] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/about Session 7 Sesmestre 1 2022] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session07 Studio] et [https://www.fun-mooc.fr/fr/cours/objectif-ipv6/?edit présentation] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session08/about Session 8 Sesmestre 1 2023] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session08 Studio]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session08/about Session 9 Sesmestre 1 2024] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session09 Studio]

== Bilan ==
[https://docs.google.com/spreadsheets/d/1PUOKsLGiOqckVbqWy1jh4ZoixsOUtKyit13ypD8x0us/edit?usp=sharing Audiences des différentes sessions]

= Documents de travail =

== Session 8 ==
* [[MOOC:Corrections s8|Corrections pour la session 8]]
* [[MOOC:Bilan Session 8|Bilan Session 8]]

== Session 7 (refonte) ==

==== Actions ====
* [[MOOC:Plan_decouverte| Plan du cours : découverte]]
* [https://miro.com/app/board/o9J_lYdjJSw=/ Tableau blanc des ateliers] (Miro)
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Taches Session 7| Liste des tâches]]
* [[MOOC:Table des corrections7|Table des corrections]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=263830683 Méta et scénarisation du cours sur FUN]

==== Comptes rendus ====

* [[MOOC:Réunion_20220121|20220121 Réunion coordination Session 7]]
* [[MOOC:Réunion_20210707|20210707 Réunion Avancement]]
* [[MOOC:Réunion_20210618|20210618 Réunion Bilan Session 6]]
* [[MOOC:Réunion_20210531|20210531 Atelier 6 : Refonte Compagnon et Seq1]]
* [[MOOC:Réunion_20210520|20210520 Atelier 5 : Renommage activités et Seq3]]
* [[MOOC:Réunion_20210503|20210503 Atelier 4 : Plan découverte et Seq4]]
* [[MOOC:Réunion_20210426|20210426 Atelier 3 : Evolution Découverte]]
* [[MOOC:Réunion_20210401|20210401 Atelier 2 : Plan découverte]]
* [[MOOC:Réunion_20210315|20210315 Atelier 1 : Structuration]]

== Guides et Aides ==
* [[MOOC:Guide de rédaction|Guide de rédaction]]
* [[MOOC:Guide de tournage|Guide de tournage]]
* [[MOOC:Guide des quizz|Guide des quizz]]
* [[MOOC:Ouverture de séquence|Guide de l'ouverture de session]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=480308602 Méta et scénarisation du cours sur FUN]

=== Informations ===
* Objectifs pédagogiques: [http://fr.wikipedia.org/wiki/Taxonomie_de_Bloom taxonomie de Bloom] (limiter aux niveaux 1, 2 voir 3)
* [[MOOC:Stats Compagnon| Statistiques sur le document compagnon]]

= Outils =
* [http://wiki.g6.asso.fr/index.php?title=Annuaire_Intervenants_MOOC Annuaire Intervenants MOOC]
* [https://docs.google.com/spreadsheets/d/1xwPM_2cbo_Fw9iTS14YyU2VpbufOT0v8NVUMRgp1I9Q/edit?usp=sharing Annuaire] (nouveau)
* Liste de diffusion [mailto:mooc-ipv6@imt-atlantique.fr mooc ipv6]
** La page d'accueil de la liste : https://listes.imt-atlantique.fr/wws/info/mooc-ipv6
** Introduction aux listes de diffusion : https://listes.imt-atlantique.fr/wws/help/introduction
* [[MOOC:Lille| Séjour à IMT Lille]]
* [http://livre.g6.asso.fr/index.php?title=Special:Search&fulltext=Search&profile=advanced Recherche sur le Wiki]
* [https://docs.google.com/document/d/1A72NHGB17awkHqUOrm-KFAjbiMb3dUdV3v-z0tRB7lA/edit Le Tableau blanc]
* [https://us04web.zoom.us/j/9708780848 Session ZOOM ]

= Archive comptes rendus de réunions =
* [[MOOC:Réunion_20201118|20201118 Point d'avancement]]
* [[MOOC:Réunion_20200615|20200615 Réunion pédago]]
* [[MOOC:Réunion_20200527|20200527 Point d'avancement]]
* [[MOOC:Réunion_20200402|20200402 Réunion pédago]]
* [[MOOC:Réunion_20200306|20200306 Réunion fin de rédaction]]
* [[MOOC:Réunion_20200212|20200212 Réunion refonte session6 2]]
* [[MOOC:Réunion_20200121|20200121 Réunion refonte session6]]
* [[MOOC:Réunion_20190927|20190927 Réunion bilan session5]]
* [[MOOC:Réunion_20190319|20190319 Réunion session5]]
* [[MOOC:Réunion_20181019|20181019 Réunion refonte]]
* [[MOOC:Réunion_20180709|20180709 Réunion bilan session 4]]
* [[MOOC:Réunion_20170306|20170306 Réunion d'avancement session3]]
* [https://docs.google.com/document/d/1hjqUmFv2WvJfgRcuBQS0mXItJRGAYqpearu2qFvCxG4/edit#heading=h.5ajsmpmo8nls 20161128 Réunion de reprise de contact]
* [https://docs.google.com/document/d/1dQn_fgq3Z8UTpW1pZ647lCisXwpU_6c-_Q0jFqNEjT8/edit#heading=h.7e8c433picx9 20160616 Réunion bilan session2]
* [[MOOC:Réunion_20160414|20160414 Réunion d'avancement2]]
* [[MOOC:Réunion_20160401|20160401 Réunion d'avancement1]]
* [[MOOC:Réunion 20160209|20160209 Réunion avant session 2]]
* [[MOOC:Réunion 20151207|20151207 Réunion bilan session1]]
* [[MOOC:Réunion 20151006|20151006 Réunion finalisation]]
* [[MOOC:Réunion 20150904|20150904 Réunion d'avancement]]
* [[MOOC:Réunion 20150311|20150311 Réunion de synchronisation]]
* [[MOOC:Réunion 20150306|20150306 Réunion d'avancement]]
* [[MOOC:Réunion 20150216|20150216 Réunion d'avancement]]
* [[MOOC:Réunion 20150203|20150203 Réunion d'avancement]]
* [[MOOC:Réunion 20150115|20150115 Réunion d'avancement]]
* [[MOOC:Réunion 20141211|20141211 Rencontre MOOC Paris]]
* [[MOOC:Réunion 20141201|20141201 Réunion d'avancement]]
* [[MOOC:Réunion 20141124|20141124 Réunion Articulation PRD/IPv6]]
* [[MOOC:Réunion 20141031|20141031 Réunion de démarrage]]

= Archives =

== Session 6 ==

==== Actions ====

* [[MOOC:Evolutions | Syllabus session 6]]
* [[MOOC:Taches Session 6| Liste des tâches]]
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Table des corrections6|Table des corrections]]

* [[MOOC:Bilan Session 6|Bilan Session 6]]

===== Animation =====

* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/ Cours en ligne]
** [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session06 Studio]
* [[MOOC:Cahier des corrections|Cahier des corrections]]

== Session 5 ==
* [[MOOC:Session_5-Taches| Liste des tâches]]
* [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session05 Studio]
* [[MOOC:Bilan_Session5|Bilan Session 5]]
* [[MOOC:Manuel_Apprenant_Session5|archive manuel apprenant session5]]

== Session 4 ==
* [[MOOC:Bilan_Session_4]]

== Session 3 ==
* [[MOOC:Taches_Session_3]]
* [[MOOC:Matrice relecture Compagnon]]
* [[MOOC:Matrice des Quiz]]
* [[MOOC:Session3-Alignement Evaluations| Alignement Evaluations]]
* [[MOOC:Bilan_Session_3]]
* [[MOOC:Erratum_Session_3]]

=== Session 2===
* [[MOOC:Taches Session 2]]
* [[MOOC:Corrections des videos]]

=== Session 1===
* [[MOOC:Formalisation de la structure]]
* [[MOOC:Figures]]
* [[MOOC:Matrice des séquences]]
* [[MOOC:Matrice des auteurs]]
* [[MOOC:Bilan Session1]]
* [[MOOC:Cahier_des_Charges_Plateforme_Lab|Cahier des charges de la plateforme Lab]]

=Communication=
* Page d'annonce du MOOC IPv6 sur FUN : [https://www.france-universite-numerique-mooc.fr/courses/MinesTelecom/04012/session01/about Objectif IPv6 : vers l'internet nouvelle génération]
* Annonces faites par l'Université de la Réunion:
** [[MOOC:comUR | Message du 15 juillet]]
** Sur le site institutionnel : [http://www.univ-reunion.fr/actualites/ipv6-le-premier-mooc-de-luniversite-de-la-reunion/ Actualités]

* Presentation du plan: https://prezi.com/jjmq_45fjhfr/mooc-objectif-ipv6-plan-du-cours/

* Pour les avis mymooc https://www.my-mooc.com/fr/mooc/objectif-ipv6-vers-linternet-nouvelle-generation/

MOOC:Compagnon Act21-s7

2023-12-15T11:21:12Z

Panelli: /* Annexe 1: la gestion de la qualité de service */

__NOTOC__

= Activité 21: L’en-tête IPv6 =


== Introduction ==
Comme rappelé en introduction de la séquence, la fonction principale du protocole IP est d'acheminer un paquet d'un point à un autre de l'Internet. Un paquet se définit comme une unité de transfert dans un réseau. Il est composé d'un bloc de données de taille variable mais limitée et identifié par un en-tête. Le mode d'acheminement par datagramme, utilisé dans l'Internet, impose que chaque paquet soit traité indépendamment, sans avoir besoin d'informations issues d'autres paquets déjà transmis. L'en-tête IP doit donc comporter toutes les informations pour réaliser cet acheminement. C'est la raison pour laquelle chaque paquet doit contenir l'adresse globale du nœud source ainsi que celle du nœud de destination du paquet. Pour marquer cette spécificité, ces paquets auto-descriptifs sont appelés des datagrammes.

L'adresse du destinataire est fondamentale pour le routage du paquet effectué par les nœuds intermédiaires. C'est en effet à partir de cette adresse que le nœud décide vers quelle interface le paquet doit sortir. La lecture de l'adresse du destinataire dans l'en-tête IP est donc une étape cruciale pour la performance globale de l'acheminement du paquet. Afin d'accélérer cette étape, deux principes ont été appliqués dans la spécification de l'en-tête IP :
* une adresse IP est de taille fixe, permettant ainsi d'être récupérée dans l'en-tête directement en lisant un nombre de bits prédéterminé, sans avoir à lire ni interpréter au préalable un champ de longueur d'adresse ;
* l'adresse IP destination est à un emplacement fixe dans l'en-tête, emplacement aligné en mémoire, facilitant ainsi son extraction de l'en-tête par un simple décalage en mémoire, qui est une opération simple au niveau matériel.

== Format de l'en-tête du datagramme IPv6 ==
Le format d'en-tête du datagramme IPv6 est spécifié par le RFC 8200 (page 5). Cet en-tête, avec les champs le composant, est représenté par la figure 1. L'en-tête IPv6 est de taille fixe et se compose de 5 mots de 64 bits (contre 5 mots de 32 bits pour IPv4). La taille de l'en-tête IPv6 est donc de 40 octets.

<center>
[[Image:21-fig1.png|400px|thumb|center|Figure 1 : Format de l'en-tête d'un paquet IPv6.]]
</center>

== Signification des champs de l'en-tête ==

=== Version ===
Le champ <tt>Version</tt> est au même emplacement et de même longueur, quelle que soit la version du protocole IP (IPv4 ou IPv6). Cette similarité permet de vérifier que le paquet reçu est au format attendu. Dans le cas d'IPv6, sa valeur est de 6 ; elle est de 4 pour IPv4. Le numéro de version 5 avait déjà été attribué au protocole Stream qui finalement n'a pas eu le succès attendu [RFC 1819].

=== Classe de trafic (''Traffic Class'') ===
Dans la version du document de spécification du protocole IPv6 [RFC 8200], le champ <tt>Classe de trafic</tt>, sur 8 bits reprend la spécification pour le codage de la différenciation de services [http://tools.ietf.org/html/rfc2474#page6 RFC 2474].

Le champ <tt>Classe de trafic</tt> est défini de façon similaire au champ <tt>Differentiated Services</tt> (DS, ou ''DiffServ'') de l'en-tête IPv4, qui a lui-même pris la place de l'octet <tt>Type of Service</tt> de la spécification initiale d'IPv4. Ce champ est découpé en deux parties (cf. figure 2). Le sous-champ DSCP (''Differentiated Services Code Point'') contient les valeurs identifiant les différents traitements demandés aux routeurs. La valeur par défaut 000000 correspond au service classique dit ''au mieux'' (ou ''best effort''). Les deux derniers bits du champ, notés ECN (''Explicit congestion Notification''), servent aux routeurs à rapporter un risque de congestion [RFC 8311].
<center>
[[Image:2015_10_10_TrafficClass.jpg|200px|thumb|center|Figure 2 : Format de l'octet <tt>classe de trafic</tt>.]]
</center>
Pour le lecteur qui veut en savoir plus, l'[[#Annexe_1:_la_gestion_de_la_qualit.C3.A9_de_service|annexe 1]] décrit l'utilisation du champ classe de trafic dans l'objectif de fournir des services de transfert à qualité différente.

=== Identificateur de flux (''Flow Label'') ===
Ce champ, contient un numéro unique, choisi par la source, pour identifier le flux de données d'une application comme par exemple l'ensemble des paquets d'une application de voix sur IP. L'unicité de l'identificateur de flux se comprend dans le contexte de l'adresse source. L'utilisation de ce champ est spécifiée par le RFC 6437.

Ce champ vise à faciliter la classification des flux par les routeurs afin de différencier le traitement des paquets et donc notamment la mise en œuvre des fonctions de qualité de service. Les datagrammes d'un même flux ayant un même identifiant, le routeur peut alors les reconnaitre et leur appliquer un traitement particulier comme le choix d'une route ou une priorité à l'accès à la transmission.

Habituellement, les routeurs se basent sur les valeurs de cinq champs pour identifier le même flux de paquets : adresses de la source et de la destination, numéros de port de la source et de la destination, et protocole. Cette identification implique l'analyse d'en-têtes de niveau 3 pour les adresses et de niveau 4 pour les autres informations.

Avec IPv6, l'identification du flux n'implique plus que le niveau 3. Ainsi, l'identification est faite indépendamment du protocole de niveau 4. Le champ <tt>Identificateur de flux</tt> peut être rempli avec une valeur aléatoire mais qui doit être unique. La source gardera cette valeur pour tous les paquets qu'elle émettra pour cette application et cette destination. Le traitement est simplifié puisque le routeur n'a plus à consulter cinq champs pour déterminer l'appartenance d'un paquet à un flux, mais un seul. De plus, la confidentialité peut être préservée, les informations concernant les numéros de port peuvent être masquées aux routeurs intermédiaires.

{{HorsTexte|Passage à l'échelle|Le passage à l'échelle désigne la capacité d'un produit ou d'un mécanisme à s'adapter à un changement d'ordre de grandeur de la demande (montée en charge), en particulier sa capacité à maintenir ses fonctionnalités et ses performances en cas de forte demande<ref>Wikipedia.[https://fr.wikipedia.org/wiki/Scalability Définition de la scalabilité]</ref>. Il faut donc comprendre qu'une difficulté à passer à l'échelle signifie que la propriété d'extensibilité n'est pas acquise.}}

À la date de rédaction de ce document, l'utilisation de l'identificateur de flux reste encore floue. Les micro-flux, c'est-à-dire les flux applicatifs, ne sont pas analysés dans le cœur du réseau pour des raisons de passage à l'échelle. De plus, l'idée d'utiliser une étiquette pour acheminer des paquets est déjà utilisée par la technologie MPLS<ref> MultiProtocol Label Switching https://fr.wikipedia.org/wiki/Multiprotocol_Label_Switching </ref> de l'Internet, ce qui retire tout sens à utiliser ce champ du paquet IPv6 pour cette fonction. Pour l'instant, ce champ peut être vu comme réservé. Son utilisation devra être détaillée dans le futur.

=== Longueur de la charge du paquet (''Payload Length'') ===

Ce champ indique la quantité d'octets qui suit l'en-tête du datagramme (en-tête exclu donc), c'est-à-dire la charge du paquet, autrement dit les données. Les éventuelles extensions à l'en-tête IPv6 sont incluses dans ces données. Ce champ, sur 16 bits, peut donc indiquer la taille des données utiles, allant jusqu'à 64 kibioctets (64 * 1024 octets). Pour des paquets dont la taille serait supérieure, ce champ vaut 0 et l'émetteur ajoute une extension d'en-tête de "proche en proche" avec l'option ''jumbogramme'' définie par le RFC 2675. Avec l'option jumbogramme, la quantité de données transportée est codée sur 32 bits. La taille maximale des données utiles du paquet monte alors jusqu'à 4 gibioctets (4* 2^30 octets). Nous reviendrons sur le jumbogramme dans l'activité "Taille des paquets IPv6".

=== En-tête suivant (''Next Header'')===
Ce champ identifie le prochain en-tête de protocole se trouvant à la suite de l'en-tête IPv6. Il peut s'agir d'un protocole de niveau supérieur (ICMP, UDP, TCP...) ou de la désignation d'une extension (cf. tableau ''Valeurs du champ en-tête suivant pour IPv6'').

<center>
{{MOOC_Valeurs_du_champ_en-tête_suivant}}
</center>

=== Nombre maximal de sauts (''Hop Limit'') ===

Ce champ représente le nombre maximal de routeurs que le paquet peut traverser. Il est initialisé par le nœud source du paquet et, ensuite, décrémenté à chaque routeur traversé. Si la valeur, après décrémentation, atteint 0, le datagramme est supprimé et un message d'erreur ICMPv6 est émis pour la source de ce paquet. Ce champ vise à limiter le nombre de relayages (ou traversées de routeurs) que peut subir un paquet suite à des problèmes dans le réseau comme des boucles de routage. Ainsi, un paquet ne peut pas circuler indéfiniment dans l'Internet.
Ce champ est à la base de l'outil <tt>traceroute</tt> pour identifier la suite des routeurs traversés jusqu'à une destination.

La valeur initiale de ce champ, à l'émission du paquet, devrait être donnée dans un document annexe de l'IANA (http://www.iana.org/) ; ce qui permettrait de la modifier en fonction de l'évolution de la topologie du réseau. La valeur n'est pas encore officiellement attribuée mais certaines implantations prennent actuellement la valeur conseillée pour IPv4 : 64.

La valeur par défaut peut être dynamiquement attribuée aux hôtes émetteurs par les annonces des routeurs en configuration automatique. Une modification de ce paramètre sera donc relativement simple quand la limite actuelle sera atteinte. On peut noter une limitation puisque ce champ, codé sur 8 bits, n'autorise la traversée que de 255 routeurs. En réalité, dans l'Internet actuel, le nombre maximal de routeurs traversés est d'une quarantaine, ce qui laisse une bonne marge pour l'évolution du réseau.

=== Adresses source et destination ===
Ces adresses sont renseignées par le nœud source du paquet pour désigner l'émetteur et le destinataire du paquet. Pour renseigner l'adresse source, l'émetteur choisit de préférence une adresse IPv6 parmi celles configurées sur l'interface utilisée pour transmettre le paquet sur le réseau. Cette adresse est choisie pour avoir une portée compatible avec l'adresse de destination et, ainsi, permettre au destinataire de répondre. Par exemple, il serait problématique d'essayer de joindre un nœud de l'Internet en donnant comme adresse source une adresse ''lien-local''. Le choix de l'adresse source est spécifié dans le RFC 6724.

L'adresse destination, elle aussi, peut être choisie dans la liste des adresses valables pour le destinataire ; liste pouvant provenir de la résolution d'un nom en adresses par le DNS. L'adresse choisie doit être compatible avec la portée des adresses disponibles au niveau de l'émetteur. Par exemple, si l'émetteur ne possède que des adresses de type ULA, et que le destinataire est connu avec des adresses globales et ULA, ces dernières adresses seront à préférer. Le RFC 6724 précise l'algorithme du choix de l'adresse destination.

=== Extensions à l'en-tête IPv6 ===
L'ajout de nouvelles fonctionnalités est problématique quand l'en-tête est de taille fixe comme c'est le cas d'IPv6. La solution proposée consiste à ajouter des en-têtes spécifiques pour chaque fonctionnalité.
Les extensions sont ajoutées par le nœud source du paquet pour demander un traitement spécifique à réaliser, soit par les routeurs intermédiaires, soit par le destinataire du paquet.
Par exemple, si un paquet doit être fragmenté, une extension de fragmentation sera ajoutée par le nœud source afin que le destinataire puisse rassembler les morceaux correctement.

Il existe plusieurs types d'extensions selon le traitement demandé. Elles se placent après l'en-tête IPv6 et avant la charge utile du paquet (voir la figure 3). La présence d'une extension est signalée par le champ <tt>En-tête suivant</tt> (''Next Header'') de l'en-tête IPv6 qui possède alors la valeur correspondant à cette extension. Ainsi, elle est traitée par les routeurs intermédiaires comme un protocole de niveau supérieur à IP. L'utilisation des différents types d'extensions d'en-tête IPv6 sera abordé dans une activité ultérieure de ce cours.

<center>
[[Image:21-fig2.jpg|400px|center|thumb|Figure 3: Format d'un paquet IPv6.]]
</center>

== Evolution de l'en-tête depuis IPv4 ==

Hormis la modification de la taille des adresses, ce qui conduit à une taille d'en-tête de 40 octets (le double d'un en-tête IPv4 sans options), le protocole IP a subi un toilettage<ref>Lee, D.C.; Lough, D.L.; Midkiff, S.F.et al. (1998). IEEE Network, Vol. 12, No. 1, January. The next generation of the Internet: aspects of the Internet protocol version 6.</ref>, reprenant l'expérience acquise au fil d’une trentaine d’années avec IPv4, défini en 1981 (!) par le RFC 791. Le format des en-têtes IPv6 est ainsi simplifié et permet aux routeurs de meilleures performances dans leurs traitements. L'idée est de retirer du cœur de réseau les traitements compliqués. Les routeurs ne font que retransmettre les paquets vers la destination, les autres traitements sont faits par l'émetteur et le destinataire du paquet.

L'en-tête ne contient plus de contrôle d'erreur (''checksum''), qui devait être ajusté, pour IPv4, par chaque routeur en raison, entre autres, de la décrémentation du champ <tt>durée de vie</tt>. Par contre, pour éviter qu'un paquet, dont le contenu est erroné -- en particulier sur l'adresse de destination --, ne se glisse dans une autre communication, tous les protocoles de niveau supérieur doivent mettre en œuvre un mécanisme de contrôle d'erreur de bout en bout, incluant un pseudo-en-tête qui prend en compte les adresses source et destination. Le contrôle d'erreur d'UDP, facultatif pour IPv4, devient ainsi obligatoire. Pour ICMPv6, le contrôle d'erreur intègre le pseudo-en-tête alors que, pour ICMPv4, il ne portait que sur le message ICMP.

La fonction de fragmentation a aussi été retirée des routeurs. Les champs de l'en-tête IPv4 qui s'y reportent (<tt>Identification, Drapeau, Place du fragment</tt>) ont été supprimés. Normalement, les algorithmes de découverte du PMTU (''Path MTU'') évitent d'avoir recours à la fragmentation. Si celle-ci s'avère nécessaire, une extension est prévue et le découpage en fragments est réalisé uniquement au niveau de l'émetteur.

Une autre évolution majeure depuis l'en-tête IPv4 est la spécification des extensions d'en-tête pour remplacer les options. En effet, dans le cas d'IPv4, les options sont incluses dans l'en-tête. Celui-ci est donc de taille variable (taille indiquée dans le champ <tt>Internet Header Length</tt>), ce qui peut compliquer le traitement dans les routeurs intermédiaires. Les extensions à l'en-tête IPv6 simplifient la mise en œuvre de ces fonctionnalités et permettent de garder la taille de l'en-tête IPv6 fixe à 40 octets.

== Conclusion ==

Cette activité a présenté l'en-tête IPv6, définissant une nouvelle version du protocole IP. Cette version reprend les caractéristiques communes du protocole IPv4 : des adresses de taille fixe, un en-tête définissant une position fixe pour l'adresse de destination, position de plus alignée en mémoire. L'objectif est d'avoir un traitement simple et donc rapide de l'en-tête dans les routeurs. IPv6 garde donc ces principes et va même plus loin que son prédécesseur IPv4 en reconsidérant des mécanismes jugés coûteux, comme la fragmentation, le ''checksum'' ou les options. Certains de ces mécanismes ont été éliminés dans la nouvelle version du protocole, d'autres remplacés par des mécanismes plus performants. Enfin, nous pouvons signaler ce formulaire qui présente l'essentiel du paquet IPv6 en une seule page<ref>Stretch, J. (2009) packetlife.net. Aide-mémoire tout en une page. [http://packetlife.net/media/library/8/IPv6.pdf IPv6]</ref>. Ceci peut vous être utile pour la suite.

== Références bibliographiques ==
<references />

== Pour aller plus loin ==

RFC et leur analyse par S. Bortzmeyer :
* RFC 791 Internet protocol (IPv4)
* RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+
* RFC 2205 Resource ReSerVation Protocol (RSVP)
* RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers [http://www.bortzmeyer.org/2474.html Analyse]
* RFC 2675 IPv6 Jumbograms
* RFC 6040 Tunnelling of Explicit Congestion Notification
* RFC 6437 IPv6 Flow Label Specification
* RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]
* RFC 7098: Using the IPv6 Flow Label for Load Balancing in Server Farms [http://www.bortzmeyer.org/7098.html Analyse]
* RFC 8200 Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]
* RFC 9098 Operational Implications of IPv6 Packets with Extension Headers [https://www.bortzmeyer.org/9098.html Analyse]



== Annexe 1: la gestion de la qualité de service ==

L'Internet différencié permet aux fournisseurs d'accès de gérer différemment les congestions qui surviennent dans le réseau. Sans différenciation, les paquets ont la même probabilité de rejet. Avec la différenciation, plusieurs classes de trafic sont définies. Les paquets appartenant aux classes les plus élevées ont une probabilité de rejet plus faible. Bien entendu, pour que l'introduction de telles classes de trafic soit efficace, il faut introduire une gestion des ressources différente pour chacune des classes, et des mécanismes de contrôle pour vérifier que les flux des utilisateurs n'utilisent pas que les classes les plus élevées ou qu'ils ne dépassent pas leur contrat. Par exemple, un client peut établir un contrat de niveau de services appelé SLA (''Service Level Agreement'') avec son fournisseur d’accès.

L'intérêt principal de la différenciation de services est qu'elle ne casse pas le modèle initial de l'Internet (version 4 ou version 6). Les flux sont toujours traités en ''Best Effort'' même si certains sont plus ''Best'' que d'autres. Il n'y a aucune garantie qu'un trafic d'une classe haute arrive à destination, mais la probabilité est plus importante. L'autre intérêt des classes de trafic vient de la possibilité d'agrégation des flux. La classe d'appartenance est indiquée dans l'en-tête du paquet. Les applications peuvent marquer les paquets en fonction de paramètres locaux (flux multimédia, flux interactif, trafic priorisé...). Le fournisseur d'accès qui récupère le trafic n'a plus à se préoccuper des applicatifs. Il vérifie que le trafic d'une classe ne dépasse pas le contrat préalablement établi.

Dans le cœur du réseau, les routeurs prennent en compte les différentes classes. Le fournisseur d'accès devra également passer des accords avec les autres opérateurs pour pouvoir faire transiter les flux avec un traitement approprié. Cet aspect de dimensionnement de réseau et de négociation d'accords d'échange est au coeur du métier d'opérateur.

Pour signifier l'appartenance d'un paquet à une certaine classe de trafic, une valeur est renseignée au niveau de l'en-tête IP dans l'octet <tt>Traffic Class</tt> afin qu'elle puisse être analysée par tous les routeurs mettant en œuvre le traitement différencié. Le format de ce champ est rappelé en figure 2.

Le tableau 1 présente les différentes valeurs définies pour le champ DSCP (''Differential Service Code Point''). Les valeurs sont présentées en format binaire avec les 6 bits les plus significatifs de l’octet <tt>Traffic Class</tt>, puis leur conversion en décimal, leur nommage, la probabilité d’écartement, et l’équivalence avec les anciennes valeurs du champ TOS de l’IPv4 :

<center>
[[Image:2015_10_07_dscp_ipv6_v01.jpg|600px|thumb|center|Tableau 1 : Format du champ DSCP.]]
</center>

Pour l'instant, deux types de comportement sont standardisés :

* Assured Forwarding [[https://tools.ietf.org/html/rfc2597#page-6 RFC 2597]] : ce comportement définit quatre classes de trafic et trois priorités, suivant que l'utilisateur respecte son contrat, le dépasse légèrement, ou est largement en dehors. Les classes sont donc choisies par l'utilisateur et restent les mêmes tout au long du trajet dans le réseau. La priorité, par contre, peut être modifiée dans le réseau par les opérateurs en fonction du respect ou non des contrats. Par exemple, pour la classe AF n°2, on dispose des 3 priorités suivantes : AF21, AF22 et AF23. Plus le chiffre est élevé, plus la priorité est faible. C'est-à-dire qu'en cas de saturation de cette classe de trafic, les paquets AF23 seront écartés avant AF22, puis AF21.
* Expedited Forwarding [[https://tools.ietf.org/html/rfc3246#page-1 RFC 3246]] : ce comportement est comparable à un circuit à débit constant réservé dans le réseau. Le trafic est mis en forme à l'entrée du réseau, en retardant l'émission des paquets qui sont hors contrat. En plus de ces comportements, l'octet DS a gardé, pour des raisons de compatibilité avec les équipements existants, les valeurs du bit ToS qui étaient le plus fréquemment utilisées. La valeur est 0xB8 (1011 1000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 46 en décimal).

* Voice Admit : cette autre valeur a été par la suite proposée dans le [https://tools.ietf.org/html/rfc5865#page-10 RFC 5865] pour affiner le traitement de flux ''temps réel'' de différentes natures : voix, vidéo, signalisation ''temps réel''… (La valeur est 0xB0 soit 1011 0000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 44 en décimal).

* Network Control : autre particularité : la valeur 0xE0 (1110 0000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 56 en décimal) correspond à CS7, la classe de contrôle du réseau (''Network Control''). Elle est utilisée dans des mises en œuvre d'IPv6 pour l'émission de certains paquets ICMPv6. Cette valeur est dépréciée. Il est conseillé d'utiliser la valeur CS6 comme spécifié dans le [https://tools.ietf.org/html/rfc4594#section-3 RFC 4594].

=== Références bibliographiques ===
* RFC 2597 Assured Forwarding PHB Group
* RFC 3246 An Expedited Forwarding PHB
* RFC 4594 Configuration Guidelines for DiffServ Service Classes
* RFC 5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic

== Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 ==

Les extensions de l'en-tête IPv6 visent à ajouter des fonctionnalités supplémentaires à l'acheminement d'un paquet dans l'Internet. Ces extensions vont impliquer le traitement de ces fonctionnalités au niveau réseau, soit par le destinataire du paquet IPv6, soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.

De nombreuses extensions ont été définies, afin d'assurer des fonctions comme le routage par la source, la gestion de la fragmentation, la confidentialité des communications (mécanisme ''ipsec''), etc.

Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme.

Cette annexe décrit les différents mécanismes qui enrichissent les fonctions disponibles au niveau de la couche réseau : routage, fragmentation, sécurité, etc. Ces mécanismes tirent parti de la possibilité d'ajouter des champs supplémentaires à l'en-tête IPv6 grâce aux extensions d'en-tête. Ces extensions sont ajoutées par les extrémités de la communication et sont transparentes pour les routeurs (exception faite des extensions de type ''Hop-by-Hop''). De plus, le mécanisme de chainage par le champ ''Next Header'' permet d'ajouter des extensions de manière souple.

L'usage des extensions est encore assez limité sur l'Internet. Certaines fonctionnalités ont été dépréciées (comme l'extension de routage RH0) et d'autres peinent à se développer (comme la mobilité IPv6). La présence potentielle de ces extensions doit être cependant prise en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.

== Principe des extensions IPv6==

Les extensions peuvent être vues comme un protocole 3.5, entre les couches 3 (réseau) et 4 (transport) du modèle OSI. En effet, à part l'extension de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6).
Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ <tt>Next header</tt> qui définit, sur un octet, le type d'extension ou de protocole qui suit. Pour les extensions de longueur variable, l'octet suivant contient la longueur de l'extension en mots de 8 octets, le premier mot n'étant pas compté. Par exemple, une extension de 16 octets aura une longueur de 1.

Si, d'un point de vue théorique, les extensions sont supérieures aux options d'IPv4, dans la réalité très peu sont utilisées à grande échelle et restent du domaine de la recherche.

'''''Nota :''''' ''dans la pratique, l'extension la plus couramment rencontrée est probablement l'option de fragmentation à la source. En effet, certains protocoles applicatifs sur UDP, tel que NFS, supposant que la fragmentation existe au niveau réseau, produisent des messages de taille quelconque sans se soucier du MTU. Comme il n'est pas envisageable de modifier ces applications largement déployées, la couche réseau IPv6 doit être capable de gérer la fragmentation. IPv6 impose simplement que cette dernière se fasse à la source.''

Une présentation illustrée des extensions IPv6 peut être consultée sur le site de Cisco<ref>Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]</ref>.

== Le champ ''Next Header'' ==

<center>
[[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ <tt>Next Header</tt> dans l'en-tête IPv6.]]
</center>
Le champ <tt>Next Header</tt> de l'en-tête IPv6, comme illustré sur la figure 1, identifie généralement le protocole de niveau supérieur comme, par exemple, le transport TCP/UDP. Mais, dans le cas des extensions, plusieurs mécanismes particuliers sont également disponibles parmi la liste suivante :
<center>{{MOOC_Valeurs_du_champ_en-tête_suivant}}
</center>

== Intégration des extensions d’en-tête dans le paquet IPv6==
Quand il y a plusieurs extensions dans un même datagramme, les extensions sont placées selon un ordre qui dépend de leur portée :
* extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;
* extensions impliquant seulement certains routeurs désignés : ''Routing'' ;
* extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.

La figure 2 montre la souplesse avec laquelle plusieurs extensions peuvent être chaînées. Chaque extension contient dans son en-tête un champ <tt>en-tête suivant</tt> et un champ <tt>longueur</tt>. Le premier paquet ne contient pas d'extension ; le champ <tt>en-tête suivant</tt> pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ <tt>en-tête suivant</tt> pointe sur TCP. Le troisième paquet contient une extension de protection qui pointe ensuite sur UDP. Dans le dernier paquet, une extension de routage, qui pointe sur une extension de fragmentation, pointe finalement sur ICMPv6.
* L'enchaînement des extensions se fait dans un ordre bien déterminé. Par exemple, une extension concernant tous les routeurs sur le chemin (''Hop-by-Hop'') devra forcément se trouver en première position. Si elle se trouvait à la suite d'une extension ''Destination'', elle ne pourrait être lue, l'extension ''Destination'' n'étant interprétée que par le destinataire du paquet.
* Si cet enchaînement d'extension offre beaucoup plus de souplesse que les options d'IPv4, il rend difficile la lecture des numéros de port. Il faut en effet lire tout l'enchaînement d'extension pour arriver au protocole de niveau 4. Ceci a servi de justification à l'identificateur de flux qui permettait de refléter au niveau 3 un flux particulier et évitait de dérouler l'enchaînement. Bien entendu, les pare-feux devront vérifier les numéros de ports.
* Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de "proche en proche", qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (''i.e.'' celui spécifié dans le champ <tt>adresse de destination</tt> du paquet IPv6).

<center>
[[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]
</center>

== Quelques exemples ==

=== Fragmentation ===

Nous avons vu la fragmentation en détail lors de l'activité consacrée à la taille des paquets IPv6. Les points essentiels à rappeler sont que la fragmentation en IPv6 est une fonction d'hôtes exclusivement, et que par souci d'efficacité, l'adaptation de la taille de l'unité de données applicatives en unité de transfert est du ressort de la couche de transport. Cependant, lorsque ce n'est pas possible, en dernier ressort, la fragmentation est faite par IPv6. Les informations pour la fragmentation sont placées dans une extension d'en-tête IPv6 identifiée par la valeur 44.
D'un point de vue du codage, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant "proche en proche" et "routage par la source") sont recopiées dans chaque fragment, tandis que les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.

La fragmentation en IPv4 n'est pas très performante. Quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, il doit le transmettre en fragments. Comme l'Internet n'est pas fiable, un fragment peut se perdre. Le destinataire ne peut rassembler les fragments. Cela revient à perdre tous les fragments. Il est donc plus efficace de faire les fragments avant la couche IP. Ainsi le fragment devient un paquet IP à la bonne taille. Maintenant, en cas de perte, seul le paquet perdu sera retransmis, évitant ainsi la retransmission de gros blocs de données.

Il est plus intéressant d'adapter la taille des paquets à l'émission. Ceci est fait en utilisant les techniques de découverte du MTU (voir RFC 8201 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de MTU 1280 octets est une bonne garantie d'acheminement du paquet.

=== Extensions d'authentification (AH) et de confidentialité (ESP) ===

L'extension d'authentification (AH : Authentication Header) décrite dans le RFC 4302 permet de s'assurer que l'émetteur du message est bien celui qu'il prétend être. Elle sert aussi au contrôle d'intégrité pour garantir au récepteur que personne n'a modifié le contenu d'un message lors de son transfert sur le réseau. Elle peut optionnellement être utilisée pour détecter les rejeux.

Le principe de l'authentification est relativement simple. L'émetteur calcule un authentificateur sur un datagramme et l'émet avec le datagramme sur lequel il porte. Le récepteur récupère cette valeur et vérifie qu'elle est correcte. Si un code d'authentification de message <ref>Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]</ref> est utilisé, il suffit au récepteur de calculer de son côté le code sur le même datagramme à l'aide de la clé symétrique partagée et de le comparer avec le code reçu. Si le mécanisme de signature numérique est employé, le récepteur doit alors récupérer la signature, la déchiffrer avec la clé publique de l'émetteur et comparer le condensat ainsi obtenu avec celui calculé de son côté sur le datagramme reçu. Si les deux codes, ou les deux condensats diffèrent, soit l'émetteur ne possède pas la bonne clé, soit le message a subi des modifications en chemin.

L'extension ESP ''Encapsulating Security Payload'' décrite dans le RFC 4303 permet de chiffrer l'ensemble des paquets ou leur partie transport et de garantir l'authentification et l'intégrité de ces paquets. Cette extension permet optionnellement de détecter les rejeux (à condition que le service d'authentification soit assuré) et garantit de façon limitée la confidentialité du flux.

Pour obtenir ces services de sécurité, il est nécessaire, avant d'émettre un paquet IP sur le réseau, de chiffrer les données à protéger, de calculer un authentificateur, et d'encapsuler ces informations dans l'en-tête de confidentialité ESP. Cela nécessite bien entendu l'existence d'une association de sécurité précisant, entre autres, le ou les algorithmes de chiffrement, la ou les clés, et un indice de paramètres de sécurité. Pour en savoir plus sur les extensions de sécurité, nous renvoyons le lecteur vers le livre<ref>G. Cizault. livre "IPv6, Théorie et Pratique". [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre sur la Sécurité]</ref>.

=== Segment Routing Header (SRH) ===

Cette extension est une des briques qui permet la mise en œuvre de l'ingénierie de trafic et de la qualité de service dans les réseaux IPv6. Certaines applications ont besoin que le délai, le taux de perte des paquets et le débit ne dépassent pas un certain seuil. Par exemple, une session de vidéo-conférence peut nécessiter que le délai de bout en bout reste inférieur à 100 ms, que le débit disponible soit au minimum de 2 Mbit/s et que le taux de perte reste inférieur à 1 %. La solution habituellement mise en œuvre pour le respect de ces métriques de qualité de service est RSVP-TE<ref>Packet Pushers, novembre 2016.[http://packetpushers.net/rsvp-te-protocol-deep-dive/ Deep dive in the RSVP-TE protocol]</ref>. RSVP est un protocole de réservation de ressources sur les routeurs du chemin entre une source et une destination. La composante d'ingénierie de trafic permet notamment de choisir explicitement le chemin qui sera suivi par le paquet. Lorsqu'une application a besoin de réserver des ressources, un circuit MPLS est établi et le protocole RSVP réserve les ressources sur l'ensemble des routeurs qui composent le chemin. La figure 4 résume ce comportement : le nœud A est la source du flot de vidéo-conférence destiné à B. Elle demande l'installation d'un chemin via MPLS. Le contrôleur détermine que le chemin le plus adapté est celui transitant par G,H,I,K,N source de vidéo-conférence. Elle effectue ensuite une réservation de ressource via RSVP. Chacun des routeurs G,H,I,K,N doit accepter la requête.

<center>
[[image:Moocipv6-act24-SRH-rsvp2.png|thumb|center|600px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]
</center>

L'inconvénient de cette méthode est qu'avec RSVP, les réservations doivent être fréquemment renouvelées et les routeurs doivent garder des états relatifs à chacun des flots. À chaque fois qu'un routeur reçoit un paquet, il doit chercher dans la liste des flots le comportement à y associer. Cela limite le passage à l'échelle (le nombre de flots supportés). De plus, l'établissement des circuits MPLS est coûteux en temps, en états, et en communication. Pour finir, si un des nœuds ou des liens qui compose le chemin n'est plus disponible, le temps requis pour établir un nouveau chemin peut être trop important face aux besoins des flots <ref>Cisco, [http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/ SR Traffic Engineering]</ref>.

Le concept de ''segment routing'' a été proposé pour palier ces désavantages. Il permet de réduire l'intelligence des nœuds du réseau. Un contrôleur choisit le chemin qui respecte les besoins de qualité de service du nœud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs en-têtes. Ces traitements à appliquer au paquet sont appelées segments. Un segment peut être l'adresse d'un routeur par lequel le paquet devra transiter, un lien à emprunter ou encore un service fourni par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémentée via une liste de labels MPLS ou, dans le cas d'un réseau IPv6, via l'option ''Segment Routing'' de l'en-tête <ref> Previdi & al. [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 IPv6 Segment Routing Header (SRH) (Draft)]</ref>. Contrairement à MPLS, le ''segment routing'' avec IPv6 ne requière pas que tous les nœuds traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et la traversée de plusieurs types de réseaux. Notons qu'il n'est pas nécessaire d'inscrire l'intégralité du chemin dans la liste. Les règles de routage classique de l'IGP s'appliquent jusqu'au prochain nœud explicitement listé dans l'en-tête. Dans le cas de la figure 5, pour suivre le chemin G,H,I,K,N, il est seulement nécessaire d'ajouter I et B dans la liste. Lorsque le paquet est généré par A, l'adresse de destination est celle de I. Lorsque le paquet atteint I, l'adresse de destination est remplacée par la prochaine dans la liste ; c'est-à-dire B. Le paquet suit le plus court chemin entre I et B ; en l’occurrence I,K,N. Le surcoût induit par la taille de l'extension de l'en-tête est donc limité.

<center>
[[image:Moocipv6-act24-SRH-rsvp.png|thumb|center|600px|Figure 5 : Exemple d'utilisation du ''Segment Routing'' pour l'ingénierie de trafic et la qualité de service.]]
</center>

Le projet de RFC prévoit qu'un segment soit représenté sur 128 bits ; c'est-à-dire autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champ <tt>Hdr Ext Len</tt> qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champ <tt>Segments Left</tt> qui indique le nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champ adresse de destination de l'en-tête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champ adresse de destination et le champ <tt>Segments Left</tt> est décrementé.

<center>
[[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 6 : Extension de routage par la source.]]
</center>

L'extension SRH est très proche de l'en-tête de routage défini dans le RFC 8200 de IPv6. L'en-tête de routage devait notamment permettre le routage à la source (voir la figure 6) qui consiste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par le RFC 5095 pour des raisons de sécurité. En effet cela permettait de générer de la congestion sur certains chemins, des attaques de déni de service, des contournements des règles de filtrages de certains pare-feux ou encore d'utiliser des machines publiques accessibles (en DMZ) pour accéder à des machines privées. <ref>P. Biondi et A. Ebalard, CanSecWest, 2017 .[http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf IPv6 Routing Header Security]</ref>.

Pour être acceptée, l'extension SRH doit donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque l'extension SRH est générée au sein du réseau de l'opérateur (i.e. routeur de bordure), les attaques listées dans le RFC 5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets provenant de l'extérieur pour éviter que des hôtes s'attribuent des privilèges ou provoquent de la congestion sur certains liens. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, le projet de RFC prévoit l'utilisation d'un mécanisme d'authentification de l'en-tête défini par le RFC 2104 (option HMAC). La clé de chiffrement de l'en-tête HMAC est distribuée au sein des nœuds autorisés à générer ou manipuler des extensions d'en-têtes SRH.

== Références bibliographiques ==
<references />

== Pour aller plus loin==
Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.

RFC et leur analyse par S. Bortzmeyer :

* RFC 4302 : IP Authentication Header
* RFC 4303 : IP Encapsulating Security Payload (ESP)
* RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]
* RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]
* RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]
* RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]
* RFC 8201 : Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]

MOOC:Corrections s8

2023-01-09T03:58:04Z

Panelli: /* Seq4 */

Remplacer les QCM à réponses multiples par des systèmes de questions à réponse simple (ex: Ajouter une proposition vraie et ajouter une proposition "toutes les propositions sont vraies")

== Seq0 ==
A02Q04 : "adresse IP" => "adresse IP publique"

Doc compagnon A02 : Donner une définition de datagramme

== Seq1 ==
A11E01 : Revoir le calcul (prise en compte des années bissextiles)
''20221212; JL : remplacement des valeurs calculées sur la base de 365,25 jours/an au lieu de 365 dans la version précédente''

A12E02 : Rappeler (doc compagnon ou dans indice) que l'IID peut être nul.

''20221212; JL : Dans l'indice il est déjà indiqué qu' "il n'y a pas d'adresse réservée dans un sous-réseau".
Ajout au doc compagnon d'un nota au paragraphe "Identification locale : l'IID (Interface IDentifier)" de l'activité A14''

Bien indiquer dans le doc compagnon qu'il n'y a pas d'adresse de broadcast

''20221212; JL : Act13, les passages concernés sont à présent en "gras".
(cf ''définition du multicast'' et ''explication groupe réservé 1, adresse <tt>ff02::1</tt>)''

Doc compagnon : expliquer les conséquences d'un subnet au delà des 64 bits ?
''20221213; JL : Ajout d'un "hors texte" au parargraphe "Préfixes de sous-réseaux (SID Subnet IDentifier)"
du doc compagnon de l'activité A14.
Doc Compagnon A13 :
* Donner des exemples de construction des adresses multicast sollicité, afin de rendre plus facile la question A13E04.
''20221214; JL : Ajout d'un exemple affichant les adresses LLA et ULA de l'interface eth0 de l'hôte cos
et les adresses multicast sur lesquelles l'interface est à l'écoute''
* Attention une redondance dans le doc compagnon sur le multicast sollicité entre le chapitre A13 et son annexe
''20221214; JL : redondances supprimées dans l'annexe et renvoi au paragraphe "Structure de l'adresse multicast" pour le format général.''
* L'exemple pour l'adresse multicast Embedded-RP du point de rendez-vous est 2001:660:3307:125::3 alors qu'à la page suivante on indique son préfixe comme étant 2001:660:3007:125/64 et l'adresse multicast dérivée ff7x:340:2001:660:3007:125:aabb:ccdd. Le 3 de 3307 du point de rendez-vous ne devrait-il pas être un 0?
''20221214; JL : corrigé''
* Aussi, dans cette section, le format pour les identifiants de groupe aabb:ccdd peut laisser croire que les deux symboles hexadécimaux qui composent un octet doivent être les mêmes, alors qu'il s'agit uniquement de marques de positions des quartets. Ça peut perturber les lecteurs qui ne sont pas familiers avec l'hexadécimal et qui pourraient penser que 11aa:77ee est un identifiant de groupe valide alors que 12ab:78ef ne l'est pas.
''20221214; JL : corrigé''

Vidéo A13 partie 1 : Au niveau du cours A13 partie 1 à la minute 7:00, le fd de l'adresse locale unique est représenté 11110001 en binaire au lieu de 11111101
'''''TODO'''''

Doc Compagnon A14 :
* donner un exemple de construction de l'IID à partir de l'adresse MAC
''20230106; JL reformulation de certaines parties du paragraphe et ajout d'un exemple extrait de la commande <tt>ifconfig</tt>''
* nouvelle structure pour les adresses multicast IPv6 ? (RFC3306 et 7371)
'''''TODO'''''
* Donner un pointeur vers une calculette subnet (exemple : https://fr.rakko.tools/tools/27/)
''20230106; JL : Ajout d'une rubrique "Ressources complémentaires" précédant la rubrique "Pour aller plus loin" avec le pointeur sur la calculatrice CIDR. Ajout d'un hors texte au paragraphe "Représentation des subdivisions" renvoyant à la cette ressource.''
* Etendre la mise en oeuvre pour Windows. J'ai lu la page 63. Il faudrait la modifier pour utiliser la terminologie Microsoft :
** Adresse IPv6 de type "Public" pour les flux entrants,
** Adresse IPv6 de type "Temporaire" pour les flux sortants.
''20230106; JL : réécriture du paragraphe "Valeur temporaire aléatoire". "Public" est ambigu (quid des contextes privatifs ULA) j'ai utlisé "adresse principale" pour les flux entrants (en renvoyant sur le paragraphe IID opaque stable). J'ai conservé l'illustration de l'antique windows XP qui reste valide et cohérente relativement au nouveau contenu du paragraphe.''

Toutes deux ont un IID généré pseudo-aléatoirement.
Cette ressource est plus claire il me semble : https://www.networkacademy.io/ccna/ipv6/ipv6-on-windows
''20230106; JL :Ajout de cette URL dans les références bibliographiques''

== Seq2 ==

Exercice A24 : Remplacer l'extension RH0 par une extension de fragmentation
''20230104; BS : création d'un nouvel exercice portant sur la fragmentation. Cf mail de Bruno pour validation''
Refaire A23 : QUIZ DOCUMENT COMPAGNON (car doublon) pour les questions
A23Q6
A23Q7
A23Q8

== Seq3 ==

S3E02 : Reformuler la question ?

TP A36 : l'étape 1 contient déjà des configurations, revoir le sujet ?

== Seq4 ==
Doc compagnon A42 / Tunnel configuré : revoir l'adressage des points d'entrée de tunnel (/64 ou /127 ?)

''20230109; PAN : Je ne vois nul part une allusion à /127. L'atelier A46 utilise /64. merci de préciser la correction à faire"

Questions A44 : Attention à l'acronyme ALG :
* A44Q01 : "Application Level Gateway"
* A44Q06 : "Application Layer Gateway"

''20230109; PAN : Retenue Application Level Gateway dans le cours et le doc compagnon"

MOOC:Compagnon Act42-s7

2023-01-09T03:55:05Z

Panelli: /* Tunnel configuré */

__NOTOC__


= <div id="connectivité">Activité 42 : Établir la connectivité en IPv6 </div> =


==Problématique==
Lorsqu'un réseau IPv6 veut joindre un autre réseau IPv6 séparé par un réseau en IPv4, le problème consiste à offrir une connectivité IPv6 entre ces deux réseaux. La bonne solution serait de les interconnecter avec IPv6 uniquement, c'est-à-dire sans avoir recours à IPv4. Mais, quand cela n'est pas possible, la connectivité s'établit par des mécanismes de niveau réseau reposant sur le principe du tunnel. Ainsi, le tunnel est la solution pour utiliser une infrastructure IPv4 existante pour acheminer du trafic IPv6<ref>Cui Y., Dong J., Wu P., et al. (2012) IEEE Internet Computing. April. Tunnel-based IPv6 Transition.</ref>.

Les tunnels peuvent s'utiliser aussi bien pour la connectivité d'un site IPv6 avec l'internet v6 (si le FAI n'offre pas encore nativement cette connectivité) que pour l'intérieur d'un site en IPv4 si celui-ci comporte des parties en IPv6 non connexes. Par la suite, nous allons décrire le fonctionnement d'un tunnel IPv6 sur IPv4 en montrant le principe du tunnel configuré et celui du tunnel automatique. De nombreuses techniques à base de tunnels existent, comme le rappelle le RFC 7059. Nous retiendrons la technique adaptée à une simple connectivité avec l'internet v6 et celle pour établir des tunnels automatiques à l'intérieur d'un site.

== Principe du tunnel IPv6 sur IPv4 ==

Le tunnel est un mécanisme bien connu dans le domaine des réseaux, qui consiste à faire qu’une unité de transfert d'un protocole (PDU ''Protocol Data Unit'') d'une couche se trouve encapsulée dans la charge utile de l'unité de transfert (PDU) d’un autre protocole de la même couche. Ainsi, des protocoles « transportés » peuvent circuler dans un réseau construit sur un protocole encapsulant. Dans le cas d'IPv6, cette technique a été définie dans le RFC 4213 et porte le nom de ''6in4''. L'encapsulation du paquet IPv6 dans le paquet IPv4 s'effectue comme illustré par la figure 1. Le paquet IPv6 occupe le champ <tt>données</tt> du paquet IPv4. Le champ <tt>protocol</tt> de l'en-tête du paquet IPv4 prend la valeur 41 (en décimal) pour indiquer qu'il encapsule un paquet IPv6. Les extrémités du tunnel peuvent être des hôtes ou des routeurs. Les nœuds, aux extrémités du tunnel, sont appelés des tunneliers (''tunnel end point'') et peuvent être configurés manuellement ou avoir une configuration dynamique. Dans ce dernier cas, on parle aussi de tunnel automatique.

<center>
[[Image:43-fig1-hd.png|300px|thumb|center|Figure 1 : Encapsulation pour un tunnel.]]
</center>

Le notion de tunnel équivaut à un câble virtuel bidirectionnel permettant d’assurer une liaison point à point entre deux nœuds IPv6 ou entre deux réseaux IPv6 et fournir ainsi une connectivité comme l’illustre la figure 2.

<center>
[[Image:43-fig2-2-hd.png|400px|thumb|center|Figure 2 : Tunnel entre des réseaux IPv6.]]
</center>

Les tunneliers sont, dans cet exemple, des routeurs en double pile. L'architecture de protocoles peut se représenter par la figure 3. Cette figure montre la réception d'un paquet en IPv6 natif et son émission dans le tunnel. La réception d'un paquet IPv6 du tunnel et son émission en natif empruntent le même chemin, mais en sens opposés. Le routeur tunnelier est un nœud qui, comme tous les routeurs, possède au moins 2 interfaces, une sur le réseau IPv4 et une sur le réseau IPv6. Cela peut être deux interfaces physiques distinctes, ou deux interfaces virtuelles sur la même interface physique. Il convient à ce stade de rappeler que les systèmes de transmission comme Ethernet ou Wi-Fi sont multiprotocoles : ils sont capables de transmettre des trames contenant des paquets IPv4 comme IPv6.

La particularité d'un tunnelier est qu'il dispose en plus d'une interface logique interne, extrémité du tunnel sur laquelle s'opère l'encapsulation / décapsulation des paquets IPv6 dans le champ "données" des paquets IPv4. Cette interface dispose d'une adresse IPv4 et d'une adresse IPv6 (GUA, ULA, ou d'une adresse, à préfixe nul "''IPv4 compatible''" ou "''IPv4 mapped''" étant donné qu'il s'agit d'une interface logique interne au routeur). Cette adresse IP sera l'adresse de « prochain saut » pour les routes vers les préfixes IPv6 à atteindre à l'autre extrémité du tunnel. Cela peut également être la route par défaut s'il s'agit d'un tunnel reliant un îlot IPv6 à l'internet v6.

<center>
[[Image:43-fig3-2.png|200px|thumb|center|Figure 3 : Architecture d'un routeur tunnelier.]]
</center>

La différence avec un lien réel porte sur la taille de la MTU. En raison de l'encapsulation dans IPv4, un tunnel se caractérise par une MTU diminuée d'une vingtaine d'octets. Ainsi, la taille du paquet IPv6 se verra limitée par rapport à la MTU du lien réel. Par exemple, si la MTU du support est de 2000 octets. Le paquet IPv4 pourra avoir une taille maximale de 2000 octets. Si Le paquet IPv6 doit emprunter un tunnel sur ce réseau. Du fait d'un taille minimale de 20 octets pour l'en-tête IPv4, la MTU utilisable par le paquet IPv6 sera de 1980 octets comme l'illustre la figure 1.
Normalement, la fragmentation et la découverte de la MTU du chemin servent à adapter la taille des paquets IPv6 à la MTU du tunnel. En pratique, des routeurs mal configurés peuvent filtrer les messages ICMP, dont le type utilisé pour la découverte de la MTU (message ICMP ''Packet Too Big''). Ceci a pour effet d'empêcher la détermination de la MTU, et donc rend la fragmentation IPv6 inopérante. Cela génère des erreurs de transmission, comme un client qui parvient a communiquer avec un serveur tant qu'il envoie des petits paquets mais qui ne reçoit rien quand il demande un fichier, c'est-à-dire quand les paquets de taille importante sont émis. Pour rappel, les paquets IPv6, lorsqu'ils ne peuvent être transmis par un routeur à cause de leur taille, sont supprimés par celui-ci. Conjointement à la destruction du paquet, le message ICMP ''Packet Too Big'' est envoyé à la source pour que celle-ci ajuste la taille du paquet.

== Tunnel configuré ==

La configuration d'un tunnel consiste à créer une interface réseau représentant l'extrémité du tunnel, indiquer les adresses IPv4 des extrémités, allouer un préfixe IPv6 pour ce lien point-à-point virtuel, et spécifier les routes pour suivre ce tunnel. Dans le cas d'un tunnel configuré, les informations de la réalisation du tunnel sont indiquées par un administrateur.

<center>
[[Image:42-fig4-2.png|300px|thumb|center|Figure 4 : Cas d'un tunnel configuré.]]
</center>

Pour illustrer la configuration d'un tunnel, la figure 4 montre le cas d'un tunnel reliant un hôte sous Linux avec un routeur. Dans cette situation, les commandes de configuration à appliquer pour l'hôte sont celles indiquées ci-dessous. La première commande crée l'interface du tunnel nommée ''6in4'' et y associe les adresses des extrémités du tunnel. Ces adresses sont l'adresse "source" et l'adresse "destination"du paquet IPv4,qui encapsulera le paquet IPv6. Ensuite l'interface du tunnel est activée. Enfin il ne reste plus qu'à configurer l'interface réseau du tunnel comme toutes les interfaces réseau d'un hôte à savoir:
* attribuer une adresse IPv6 et indiquer le préfixe réseau du lien (ici le tunnel),
* indiquer la route par défaut passant par le routeur local.

ip tunnel add 6in4 mode sit remote 192.0.3.1 local 192.0.2.1
ip link set dev 6in4 up

ip -6 addr add 2001:db8:caf:1::2/64 dev 6in4
ip -6 route add ::/0 via 2001:db8:caf:1::1 dev 6in4

Les performances d'un tunnel vont dépendre de sa longueur. Pour éviter d'avoir des délais trop importants, il convient de configurer un tunnel vers le point IPv6 le plus proche.

=== Connectivité d'un site isolé : ''Tunnel Broker''===

La croissance du réseau IPv6 a commencé en s'appuyant sur l'infrastructure de communication de IPv4. Les premiers tunnels étaient configurés manuellement et pouvaient être très longs (et donc peu performants). La longueur d'un tunnel s'apprécie par le nombre de sauts IPv4 ou la distance qui sépare les 2 extrémités du tunnel. Pour des personnes non qualifiées, ceci reste complexe tant du point de vue technique que du point de vue du choix du point de sortie du tunnel. La constitution d'un tunnel a été simplifiée par l'introduction du ''Tunnel Broker'' [RFC 3053]. Les ''Tunnel Brokers'' représentent une méthode pour connecter un réseau IPv6 à l’internet v6. L'idée du ''Tunnel Broker'' consiste à mettre en œuvre une interaction de type "client/serveur". La partie cliente est localisée côté utilisateur tandis que la partie serveur traite les demandes de tunnels. Le modèle du ''Tunnel Broker'' est représenté par la figure 5.
<center>
[[image: 42-fig5-2.png |250px|thumb|center|Figure 5 : Modèle du ''Tunnel Broker''.]]
</center>

La création d'un tunnel à l'aide d'un ''Tunnel Broker'' fonctionne de la manière indiquée par la figure 6 ; à savoir :
# Une machine "double pile" du réseau IPv6 (typiquement un routeur) négocie avec le ''Tunnel Broker'' afin de s'authentifier et d'obtenir les informations de configuration du tunnel ainsi qu'un préfixe délégué.
# Le ''Tunnel Broker'' configure le serveur de tunnel retenu.
# Le ''Tunnel Broker'' envoie le script de configuration à la machine "double pile" coté utilisateur.
# Cette dernière, en exécutant le script reçu, crée le tunnel. Elle va ensuite encapsuler ses paquets IPv6 dans des paquets IPv4 à destination du serveur de tunnels, qui sert également de routeur. Ainsi, une communication en IPv6 peut s'effectuer entre des nœuds d'un réseau IPv6 isolé avec des nœuds de l'internet v6.

<center>
[[image:42-fig6-2.png |350px|thumb|center|Figure 6 : Configuration d'un ''Tunnel Broker'' avec TSP.]]
</center>

La négociation est opérée à l'aide du protocole TSP (''Tunnel Set Up Protocol'') [RFC 5572]. En l'absence de TSP, la demande de connexion au ''Tunnel Broker'' est réalisée par une interface web dont l'URL est connue à l'avance. Par cette interface, les paramètres nécessaires à l'établissement du tunnel entre le nœud de l'utilisateur et le serveur de tunnels sont récupérés. Le protocole de négociation TSP automatise cet échange. Plus précisément, TSP traite les paramètres suivants :
* l'authentification de l'utilisateur ;
* le type de tunnel :
** tunnel IPv6 sur IPv4 [RFC 4213],
** tunnel IPv4 sur IPv6 [RFC 2473],
** tunnel IPv6 sur UDP-IPv4 pour la traversée de NAT ;
* les adresses IPv4 pour les deux extrémités du tunnel ;
* l'adresse IPv6 assignée lorsque le client TSP est un terminal ;
* le préfixe IPv6 alloué lorsque le client TSP est un routeur.

TSP s'appuie sur l'échange de simples messages XML dont un exemple est donné ci-dessous. Cet exemple correspond à la demande de création d'un tunnel simple par un client TSP :

-- Successful TCP Connection --
C:VERSION=2.0.0 CR LF
S:CAPABILITY TUNNEL=V6V4 AUTH=ANONYMOUS CR LF
C:AUTHENTICATE ANONYMOUS CR LF
S:200 Authentication successful CR LF
C:Content-length: 123 CR LF
<tunnel action="create" type="v6v4">
<client>
<address type="ipv4">1.1.1.1</address>
</client>
</tunnel> CR LF
S: Content-length: 234 CR LF
200 OK CR LF
<tunnel action="info" type="v6v4" lifetime="1440">
<server>
<address type="ipv4">206.123.31.114</address>
<address type= "ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0000</address>
</server>
<client>
<address type="ipv4">1.1.1.1</address>
<address type= "ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
<address type="dn">userid.domain</address>
</client>
</tunnel> CR LF
C: Content-length: 35 CR LF
<tunnel action="accept"></tunnel> CR LF

La connectivité offerte par les ''Tunnel Brokers'' est en général fournie à titre provisoire (soit en attendant que l'offre des FAI soit disponible, soit pour faire des tests de validation, par exemple). Elle peut aussi être une première étape pour un prestataire de services pour procurer de la connectivité IPv6 à ses usagers.
Afin de promouvoir le passage à IPv6, les ''Tunnel Brokers'' sont souvent gratuits<ref>Linux Review. [http://en.linuxreviews.org/Free_IPv4_to_IPv6_Tunnel_Brokers Free IPv4 to IPv6 Tunnel Brokers]</ref>. Lorsque le ''Tunnel Broker'' a une faible répartition géographique de ses serveurs de tunnels, pour certains utilisateurs, la longueur des tunnels reste un problème.

== Tunnel automatique ==

Un tunnel configuré demande un travail de configuration pour chaque tunnel, ce qui peut être vu comme un inconvénient. Avec l'automatisation, l'intervention de l'administrateur est réduite à une phase de "configuration/initialisation" du service, à la place de celle de configuration des tunnels.
Ainsi, des solutions d'automatisation ont été étudiées, qui ont comme principe de contenir l'adresse IPv4 du tunnelier de destination dans l'adresse IPv6 de destination. Ce principe d'embarquer l'adresse du tunnelier dans l'adresse IPv6 au niveau du préfixe est présenté par le RFC 3056 et connu sous le nom de ''6to4''.
La figure 7 montre le cas d'application du tunnel automatique selon le principe ''6to4''. Il s'agit de relier un réseau IPv6 qui n'a pas de lien en IPv6 à l'internet IPv6. La connectivité va être effectuée au moyen d'un tunnel automatique à l'aide d'un réseau IPv4 auquel le réseau IPv6 est relié via un routeur en double pile. Ce routeur se situe en bordure des réseaux IPv4 et IPv6. On appellera un tel routeur, tunnelier (''Tunnel end point'').

<center>
[[Image:43-fig7-3.png|300px|thumb|center|Figure 7 : Cas d'application d'un tunnel automatique.]]
</center>

Comme pour ''6in4'', l'encapsulation des paquets IPv6 avec un tunnel automatique s'effectue dans les paquets IPv4. Par contre, au niveau de l'adressage, avec les tunnels automatiques, il faut définir un préfixe IPv6 spécifique qui indique qu'une adresse IPv4 est embarquée. La figure 8 illustre le mécanisme de construction d'un préfixe. Comme indiqué précédemment, le tunnelier se trouve en bordure du réseau. Il est connecté à la fois à l'internet v4 et à un réseau IPv6. C'est un nœud en double pile ; il possède obligatoirement une adresse IPv4 "unicast globale", comme <tt>192.0.2.1</tt> dans l'exemple. Retenons le préfixe spécifique '''<tt>2002::/16</tt>'''. Le préfixe du réseau IPv6 va être composé en concaténant le préfixe spécifique et l'adresse IPv4 "unicast globale" du tunnelier de ce réseau IPv6. Le préfixe du réseau IPv6 embarquant l'adresse IPv4 aura une longueur de 48 bits dans notre exemple et aura la valeur
<tt>2002:c000:201::/48</tt> (0xc0 = 192). Il est à noter qu'il a la même longueur que la partie publique d'un préfixe IPv6 GUA.

<center>
[[image:43-fig8-2-hd.png|300px|thumb|center|Figure 8 : Construction d'un préfixe IPv6 à partir de l'adresse IPv4 du tunnelier.]]
</center>

Aussi, comme le montre la figure 9, le préfixe de 48 bits laisse un champ SID de 16 bits pour numéroter des sous-réseaux ou liens dans le réseau IPv6. Il est alors possible d'attribuer des adresses au différents nœuds du réseau IPv6. Ils auront en commun d'avoir l'adresse IPv4 de leur tunnelier dans la partie préfixe de leur adresse.

<center>
[[image:43-fig6-hd.png|400px|thumb|center|Figure 9 : Format d'une adresse construite sur la base d'une connectivité par un tunnel.]]
</center>

La figure 10 présente l'envoi d'un paquet IPv6 de l'hôte A vers l'hôte B. Dans un premier temps, A interroge le DNS pour connaître l'adresse IPv6 de B. Dans notre exemple, la réponse est <tt>2002:c000:201:1::8051</tt>. Dans un second temps, l'hôte A émet le paquet vers cette destination. Ce paquet IPv6, dont l'adresse de destination commence par le préfixe <tt>2002::/16</tt>, est acheminé vers un tunnelier de l'internet v6. Lorsque le paquet est reçu par le tunnelier. Ce dernier analyse l'adresse IPv6 de destination et trouve l'adresse IPv4 de l'autre extrémité du tunnel (<tt>192.0.2.1</tt> dans l'exemple). Il effectue alors la transmission du paquet IPv6 en l'encapsulant dans un paquet IPv4. C'est cette encapsulation qui forme le tunnel. Le tunnelier du coté de B désencapsule le paquet IPv6 et le route normalement vers sa destination finale B en utilisant le routage interne.

<center>
[[image:43-fig10-3-hd.png|400px|thumb|center|Figure 10 : Envoi d'un paquet IPv6 en passant par un tunnel automatique.]]
</center>

Le principe des tunnels automatique de type ''6to4'' est intéressant en théorie mais en pratique, il reste le problème des tunneliers du coté de l'internet v6. En effet, à qui incombe la responsabilité d'installer ces tunneliers ? Une réponse a été le fournisseur d'accès à Internet pour ses clients. C'est dans ce contexte que la technique ''6rd'' a été proposée et que nous allons voir dans la section suivante.

=== Connectivité sur une infrastructure IPv4 : ''6rd'' ===

Le mécanisme ''6rd'' (''IPv6 Rapid Deployment''), proposé par le RFC 5569 après son déploiement par Free, a été étendu pour devenir un standard par le RFC 5969. ''6rd'' reprend le principe des tunnels automatiques du ''6to4'' en ciblant son application à un opérateur offrant une connectivité IPv6 et dont l'infrastructure repose sur IPv4. Cet opérateur peut être aussi bien public, comme un FAI, ou privé, comme une entreprise ou une administration.

L'idée de ''6rd'' porte sur l'utilisation d'un préfixe IPv6 propre à l'opérateur. Sa mise en oeuvre oblige l'opérateur à avoir le contrôle des 2 extrémités du tunneI. Autrement dit, il lui appartient d'installer un routeur de bordure connecté à l'internet v6. Il s'ensuit que les tunnels utilisés dans le contexte de ''6rd'' sont de longueur limitées à la taille du réseau IPv4 de l'opérateur. Il sont de fait court et ne sont pas sensés traverser l'internet. Les tunnels automatiques ''6rd'' ne servent qu'à passer la section IPv4 de l'opérateur. Avec ''6rd'', on se retrouve dans le cas classique où les routeurs internes (dont les tunneliers) traitent le trafic produit et destiné aux hôtes connectés à l'opérateur.
En fait, l'idée de ''6rd'' est de limiter la technique des tunnels automatiques pour un usage interne et local.

Dans la figure 11, qui schématise l'architecture de ''6rd'', le routeur de bordure est noté, selon la terminologie du RFC 5969, "''6rd'' BR"(''Border Relays''). Ce routeur est un tunnelier connecté en IPv4 du coté du l'infrastructure de communication de l'opérateur et connecté en IPv6 du coté de l'internet v6. Le réseau local IPv6 du coté de l'abonné est connecté à l'infrastructure de communication de l'opérateur à l'aide d'un tunnelier. Ce dernier appelé "''6rd'' CE" (''Customer Edge''), est également un routeur en "double pile". Concrètement, on le trouve sous la forme de la "box" dans l'installation des abonnés de l'opérateur. Chacun de ces tunneliers possèdent une adresse IPv4 sur l'interface réseau de l'infrastructure notée par exemple a4 pour le réseau local A. De manière similaire au principe utilisé dans ''6to4'', le préfixe IPv6 du réseau local est constitué en embarquant l'adresse IPv4 dans le préfixe IPv6 propre à cet opérateur noté <tt>pref6rd</tt>. Le préfixe IPv6 du réseau local est noté dans la figure 11 pour le réseau A <tt>pref6rd:a4::</tt>.
La figure 12 montre que la connectivité en IPv6 peut être établie entre 2 hôtes par un tunnel entre 2 ''box'' ou entre une box et le routeur de bordure afin qu'un hôte puisse accéder à l'internet v6. Dans les deux cas, un tunnel automatique est établi pour passer l'infrastructure de communication centrale fonctionnant en IPv4.

<center>
[[Image:43-fig12a-hd.png|350px|thumb|center|Figure 11 : Architecture de ''6rd''.]]
</center>

Le format de l’adresse IPv6 ''6rd'' dérive d'un préfixe <tt>2000::/3</tt> pris dans le plan d'adressage global unicast (''GUA''). Il utilise le préfixe propre alloué au FAI par son registre régional (RIR). Il devient difficile de différencier un trafic sortant d’un réseau ''6rd'' d’un trafic IPv6 natif car les deux partagent le même préfixe. Le préfixe IPv6 du domaine de l'opérateur est complété par tout ou partie de l'adresse IPv4 alloué au ''6rd'' CE", pour former le préfixe ''6rd''. Le "''6rd'' CE" est l'extrémité du tunnel coté client (dans la figure 11) et connue comme la box fournie par le FAI. L'adresse IPv4 du routeur "''6rd'' CE" est normalement publique, mais ce n’est pas obligatoire. L’organisation de l’adresse IPv6 est décrite par la figure 13. À noter que, au sein d'un même opérateur, si les adresses IPv4 s'agrègent sur un préfixe commun, il n'est pas nécessaire d'encoder la totalité des 32 bits de l'adresse IPv4 dans le préfixe IPv6 ; ce qui libère des bits pour laisser une numérotation des liens internes (SID) au réseau IPv6 à connecter. Il est laissé le soin à chaque opérateur de définir le nombre de bits de l'adresse IPv4 à conserver. La seule contrainte est que le préfixe réseau ne doit pas dépasser 64 bits autrement dit n + i + s bits = 64 bits
<center>
[[Image:43-fig13-hd.png|400px|thumb|center|Figure 12 : Format d'une adresse ''6rd''.]]
</center>

Pour illustrer la figure 12, considérons tout d’abord que l’adresse IPv4 <tt>192.0.2.129</tt> (c000:281 en hexadécimal) a été attribuée à l’interface du"''6rd'' CE" du réseau local A de la figure 11. L'opérateur dispose du préfixe IPv6 <tt>2001:db8::/32</tt> pour son domaine ''6rd''. Les adresses de tous les "''6rd'' CE" s'agrègent sur le préfixe <tt>192.0.0.0/8</tt>. L'opérateur peut garder 24 bits comme partie significative. Les 24 bits de poids faible de l'adresse IPv4 suffisent, en effet, à distinguer chacun des "''6rd'' CE" de son réseau. Les 8 bits du préfixe IPv4 (valeur décimale 192 dans notre exemple) peuvent être omis. Le préfixe IPv6 de chaque "''6rd'' CE" aura donc une longueur de 56 bits, correspondant à l'addition du préfixe du domaine (32 bits) avec la partie significative de l'adresse IPv4 (24 bits). Dans le cas de l'exemple, la figure 13 illustre cet assemblage entre le préfixe de l'opérateur et l'adresse IPv4. Pour plus de lisibilité, la partie significative de l'adresse IPv4 a été laissée en notation décimale pointée sur la figure. En notation de l'adresse IPv6, le ''6rd delegated prefix'' pour le "''6rd'' CE" d'adresse <tt>192.0.2.129</tt> sera <tt>2001:db8:2:8100::/56</tt>. Il restera alors 8 bits, au titre du SID (''Subnet Identifier''), pour la numérotation des sous-réseaux internes du réseau connecté par le "''6rd'' CE". À l’extérieur de l'opérateur, les adresses IPv6 apparaîtront comme des adresses IPv6 natives. À l'intérieur de l'opérateur, les adresses seront interprétées pour établir un tunnel entre les routeurs de bordures de l'infrastructure IPv4 de l'opérateur.

<center>
[[Image:43-fig14-hd.png|400px|thumb|center|Figure 13 : Exemple de construction d'un préfixe délégué ''6rd''.]]
</center>

Le transfert avec la technique ''6rd'' s'organise selon 3 cas :

* transfert inter-réseau IPv6 local. La figure 12 illustre ce cas lorsque les 2 hôtes souhaitent communiquer. La source de préfixe "pref6rd:a4" envoie un paquet IPv6 à destination de l'hôte de préfixe "pref6rd:b4". Le paquet IPv6 arrive en mode natif au "''6rd'' CE" de la source. Si l’adresse IPv6 de destination est incluse dans le préfixe du domaine ''6rd'' configuré localement, il sera transmis directement à l'autre "''6rd'' CE" comme c'est le cas ici. Les adresses IPv4 des "''6rd'' CE" sont extraites des adresses IPv6 pour constituer le tunnel. Le paquet IPv4, d'adresse source "a4" et d'adresse destination "b4", encapsule le paquet IPv6. Ce paquet IPv4 est acheminé au "''6rd'' CE" de destination par l'infrastructure IPv4 de l'opérateur. Le routeur "''6rd'' CE" de destination reçoit le paquet IPv4. Il vérifie, par mesure de sécurité, que l'adresse source de l'en-tête IPv4 correspond à celle intégrée dans l'adresse IPv6 source. Il désencapsule le paquet IPv6 et le transmet sur le réseau local pour son acheminement à la destination IPv6 ;
* transfert du réseau local IPv6 vers l'internet v6. Le trafic IPv6 est reçu en mode natif sur le "''6rd'' CE". L'adresse de destination IPv6 ne correspond pas à un préfixe IPv6 du domaine de l'opérateur, ce qui signifie que la destination est extérieure au domaine de ''6rd'' local. Dans ce cas, le paquet IPv6 doit être transmis à un routeur de bordure ''6rd''. Comme dans le cas du transfert inter-site, le paquet IPv6 est encapsulé dans un paquet IPv4. Cependant, la différence est que l'adresse IPv4 du routeur de bordure est obtenue dans la table de routage du "''6rd'' CE". Le routeur de bordure reçoit le paquet IPv4 et supprime l'encapsulation IPv4. Après le contrôle de sécurité, le paquet IPv6 est transmis sur l'internet v6 ;
* transfert de l'internet v6 vers le site. Si un routeur de bordure reçoit un paquet IPv6 à destination d’une adresse IPv4 incluse dans le préfixe ''6rd'' du domaine, il transmet le paquet au routeur "''6rd'' CE" correspondant en utilisant le même principe que le cas précédent. Dans le cas du trafic retour, d'un flux initialisé par une machine ''6rd'', comme l'adresse de destination est issue du préfixe global de l'opérateur, la voie retour passera par le même relais. Ainsi, la communication s'effectuera en empruntant la même route à l'aller et au retour.

La technique ''6rd'' est adaptée à une mise en œuvre locale d’IPv6 pour un opérateur dont l'infrastructure interne fonctionne encore en IPv4<ref>Cisco. (2011). White paper. [http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/whitepaper_c11-665758.html IPv6 Rapid Deployment: Provide IPv6 Access to Customers over an IPv4-Only Network]</ref>. Cette technique de tunnel répond à des questions de fiabilité et de délai. Comme le relais avec l'internet v6 est administré par, et pour, l'opérateur lui-même, le service de connectivité peut être de bonne qualité. En cas de défaillance, la responsabilité de l'opérateur est directement engagée.

== Conclusion==

Dans la démarche d'intégration d'IPv6, la meilleure solution est d'utiliser IPv6 nativement, comme IPv4. La complexité supplémentaire induite par les tunnels, ainsi que la réduction de la MTU qu'ils imposent (entraînant des problèmes de connectivité "épisodiques") sont épargnées. Mais il n'est pas toujours possible de maintenir la connectivité IPv6 ou de trouver un opérateur offrant la connectivité IPv6. Alors, dans ces situations, il faut se résoudre à utiliser des tunnels. Le RFC 7059 effectue un inventaire des techniques d'intégration reposant sur des tunnels. Toutes les techniques ne se valent pas du point de vue des performances et de la fiabilité. Les meilleures techniques sont celles qui établissent des tunnels locaux ou de courte distance et pour lesquelles les extrémités du tunnel sont gérées et offrent un service contractuel. Le choix d'une technique de tunnel doit se faire en fonction des besoins de connectivité du réseau dans lequel IPv6 doit être intégré.

Nous avons présenté, dans cette activité, les techniques les plus intéressantes pour établir une connectivité IPv6. Le ''tunnel broker'' représente une méthode pour tirer un simple tunnel entre un réseau IPv6 isolé et un point d'entrée de l'internet v6. Les techniques ''6to4'' et ''6rd'' utilisent des tunnels automatiques au sein du réseau IPv4 d'une organisation. Si le principe de tunnel automatique de ''6to4'' est pertinent, sa mise en œuvre a été problématique. La dépréciation récente du préfixe anycast réservé à son usage entraîne, de fait, son déclin. La variante ''6rd'', en corrigeant les défauts de ''6to4'', se positionne comme une alternative.

''6rd'' repose sur l'encapsulation directe : le paquet IPv6 est placé directement dans un paquet IPv4. Ce mode d'encapsulation ne traverse pas les NAT car les NAT ont, pour la plupart, la capacité de traiter uniquement les protocoles de transport TCP et UDP. La technique de tunnel Teredo [RFC 4380] traite ce problème en encapsulant les paquets IPv6 dans UDP puis dans IPv4. Il a été reporté par l'article<ref>Huston, G. (2011). The ISP Column. [http://www.potaroo.net/ispcol/2011-04/teredo.html Testing Teredo]</ref> des performances et une fiabilité du service de connectivité de très mauvaise qualité. Cette solution comme ''6to4'' ont négligé la mise en oeuvre opérationnelle et ne sont plus utilisées de nos jours.

Pour conclure, nous rappelons la règle habituelle de connectivité d'IPv6 qui dit : « double-pile où tu peux, tunnel où tu dois » (''Dual stack where you can; tunnel where you must''). La double-pile (IPv4 et IPv6 sur tous les équipements) est la solution la plus simple pour la gestion du réseau. Le tunnel est plus fragile et fait dépendre IPv6 d'IPv4. Il sert dans les situations où des routeurs antédiluviens ne peuvent être mis à jour pour traiter des paquets IPv6. Le tunnel est solution d'attente avant le remplacement par un équipement moderne.

==Références bibliographiques==
<references />

== Pour aller plus loin ==

RFC et leur analyse par S. Bortzmeyer :
* RFC 2473 Generic Packet Tunneling in IPv6 Specification
* RFC 3053 IPv6 Tunnel Broker
* RFC 3056 Connection of IPv6 Domains via IPv4 Clouds
* RFC 3068 An Anycast Prefix for 6to4 Relay Routers
* RFC 4213 Basic IPv6 Transition Mechanisms [http://www.bortzmeyer.org/4213.html Analyse]
* RFC 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
* RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [http://www.bortzmeyer.org/5569.html Analyse]
* RFC 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) [http://www.bortzmeyer.org/5572.html Analyse]
* RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [http://www.bortzmeyer.org/5969.html Analyse]
* RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]
* RFC 6343 Advisory Guidelines for 6to4 Deployment
* RFC 6782 Wireline Incremental IPv6 [http://www.bortzmeyer.org/6782.html Analyse]
* RFC 7059 A Comparison of IPv6 over IPv4 Tunnel Mechanisms [http://www.bortzmeyer.org/7059.html Analyse]
* RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]
* RFC 7526 Deprecating Anycast Prefix for 6to4 Relay Routers [http://www.bortzmeyer.org/7526.html Analyse]

MOOC:Compagnon Act42-s7

2023-01-09T03:35:49Z

Panelli: /* Tunnel configuré */

__NOTOC__


= <div id="connectivité">Activité 42 : Établir la connectivité en IPv6 </div> =


==Problématique==
Lorsqu'un réseau IPv6 veut joindre un autre réseau IPv6 séparé par un réseau en IPv4, le problème consiste à offrir une connectivité IPv6 entre ces deux réseaux. La bonne solution serait de les interconnecter avec IPv6 uniquement, c'est-à-dire sans avoir recours à IPv4. Mais, quand cela n'est pas possible, la connectivité s'établit par des mécanismes de niveau réseau reposant sur le principe du tunnel. Ainsi, le tunnel est la solution pour utiliser une infrastructure IPv4 existante pour acheminer du trafic IPv6<ref>Cui Y., Dong J., Wu P., et al. (2012) IEEE Internet Computing. April. Tunnel-based IPv6 Transition.</ref>.

Les tunnels peuvent s'utiliser aussi bien pour la connectivité d'un site IPv6 avec l'internet v6 (si le FAI n'offre pas encore nativement cette connectivité) que pour l'intérieur d'un site en IPv4 si celui-ci comporte des parties en IPv6 non connexes. Par la suite, nous allons décrire le fonctionnement d'un tunnel IPv6 sur IPv4 en montrant le principe du tunnel configuré et celui du tunnel automatique. De nombreuses techniques à base de tunnels existent, comme le rappelle le RFC 7059. Nous retiendrons la technique adaptée à une simple connectivité avec l'internet v6 et celle pour établir des tunnels automatiques à l'intérieur d'un site.

== Principe du tunnel IPv6 sur IPv4 ==

Le tunnel est un mécanisme bien connu dans le domaine des réseaux, qui consiste à faire qu’une unité de transfert d'un protocole (PDU ''Protocol Data Unit'') d'une couche se trouve encapsulée dans la charge utile de l'unité de transfert (PDU) d’un autre protocole de la même couche. Ainsi, des protocoles « transportés » peuvent circuler dans un réseau construit sur un protocole encapsulant. Dans le cas d'IPv6, cette technique a été définie dans le RFC 4213 et porte le nom de ''6in4''. L'encapsulation du paquet IPv6 dans le paquet IPv4 s'effectue comme illustré par la figure 1. Le paquet IPv6 occupe le champ <tt>données</tt> du paquet IPv4. Le champ <tt>protocol</tt> de l'en-tête du paquet IPv4 prend la valeur 41 (en décimal) pour indiquer qu'il encapsule un paquet IPv6. Les extrémités du tunnel peuvent être des hôtes ou des routeurs. Les nœuds, aux extrémités du tunnel, sont appelés des tunneliers (''tunnel end point'') et peuvent être configurés manuellement ou avoir une configuration dynamique. Dans ce dernier cas, on parle aussi de tunnel automatique.

<center>
[[Image:43-fig1-hd.png|300px|thumb|center|Figure 1 : Encapsulation pour un tunnel.]]
</center>

Le notion de tunnel équivaut à un câble virtuel bidirectionnel permettant d’assurer une liaison point à point entre deux nœuds IPv6 ou entre deux réseaux IPv6 et fournir ainsi une connectivité comme l’illustre la figure 2.

<center>
[[Image:43-fig2-2-hd.png|400px|thumb|center|Figure 2 : Tunnel entre des réseaux IPv6.]]
</center>

Les tunneliers sont, dans cet exemple, des routeurs en double pile. L'architecture de protocoles peut se représenter par la figure 3. Cette figure montre la réception d'un paquet en IPv6 natif et son émission dans le tunnel. La réception d'un paquet IPv6 du tunnel et son émission en natif empruntent le même chemin, mais en sens opposés. Le routeur tunnelier est un nœud qui, comme tous les routeurs, possède au moins 2 interfaces, une sur le réseau IPv4 et une sur le réseau IPv6. Cela peut être deux interfaces physiques distinctes, ou deux interfaces virtuelles sur la même interface physique. Il convient à ce stade de rappeler que les systèmes de transmission comme Ethernet ou Wi-Fi sont multiprotocoles : ils sont capables de transmettre des trames contenant des paquets IPv4 comme IPv6.

La particularité d'un tunnelier est qu'il dispose en plus d'une interface logique interne, extrémité du tunnel sur laquelle s'opère l'encapsulation / décapsulation des paquets IPv6 dans le champ "données" des paquets IPv4. Cette interface dispose d'une adresse IPv4 et d'une adresse IPv6 (GUA, ULA, ou d'une adresse, à préfixe nul "''IPv4 compatible''" ou "''IPv4 mapped''" étant donné qu'il s'agit d'une interface logique interne au routeur). Cette adresse IP sera l'adresse de « prochain saut » pour les routes vers les préfixes IPv6 à atteindre à l'autre extrémité du tunnel. Cela peut également être la route par défaut s'il s'agit d'un tunnel reliant un îlot IPv6 à l'internet v6.

<center>
[[Image:43-fig3-2.png|200px|thumb|center|Figure 3 : Architecture d'un routeur tunnelier.]]
</center>

La différence avec un lien réel porte sur la taille de la MTU. En raison de l'encapsulation dans IPv4, un tunnel se caractérise par une MTU diminuée d'une vingtaine d'octets. Ainsi, la taille du paquet IPv6 se verra limitée par rapport à la MTU du lien réel. Par exemple, si la MTU du support est de 2000 octets. Le paquet IPv4 pourra avoir une taille maximale de 2000 octets. Si Le paquet IPv6 doit emprunter un tunnel sur ce réseau. Du fait d'un taille minimale de 20 octets pour l'en-tête IPv4, la MTU utilisable par le paquet IPv6 sera de 1980 octets comme l'illustre la figure 1.
Normalement, la fragmentation et la découverte de la MTU du chemin servent à adapter la taille des paquets IPv6 à la MTU du tunnel. En pratique, des routeurs mal configurés peuvent filtrer les messages ICMP, dont le type utilisé pour la découverte de la MTU (message ICMP ''Packet Too Big''). Ceci a pour effet d'empêcher la détermination de la MTU, et donc rend la fragmentation IPv6 inopérante. Cela génère des erreurs de transmission, comme un client qui parvient a communiquer avec un serveur tant qu'il envoie des petits paquets mais qui ne reçoit rien quand il demande un fichier, c'est-à-dire quand les paquets de taille importante sont émis. Pour rappel, les paquets IPv6, lorsqu'ils ne peuvent être transmis par un routeur à cause de leur taille, sont supprimés par celui-ci. Conjointement à la destruction du paquet, le message ICMP ''Packet Too Big'' est envoyé à la source pour que celle-ci ajuste la taille du paquet.

== Tunnel configuré ==

La configuration d'un tunnel consiste à créer une interface réseau représentant l'extrémité du tunnel, indiquer les adresses IPv4 des extrémités, allouer un préfixe IPv6 pour ce lien point-à-point virtuel, et spécifier les routes pour suivre ce tunnel. Dans le cas d'un tunnel configuré, les informations de la réalisation du tunnel sont indiquées par un administrateur.

<center>
[[Image:42-fig4-2.png|300px|thumb|center|Figure 4 : Cas d'un tunnel configuré.]]
</center>

Pour illustrer la configuration d'un tunnel, la figure 4 montre le cas d'un tunnel reliant un hôte sous Linux avec un routeur. Dans cette situation, les commandes de configuration à appliquer pour l'hôte sont celles indiquées ci-dessous. La première commande crée l'interface du tunnel nommée ''6in4'' et y associe les adresses des extrémités du tunnel. Ces adresses sont l'adresse "source" et l'adresse "destination"du paquet IPv4,qui encapsulera le paquet IPv6. Ensuite l'interface du tunnel est activée. Enfin il ne reste plus qu'à configurer l'interface réseau du tunnel comme toutes les interfaces réseau d'un hôte à savoir:
* attribuer une adresse IPv6 et indiquer le préfixe réseau du lien (ici le tunnel),
* indiquer la route par défaut passant par le routeur local.

ip tunnel add 6in4 mode sit remote 192.0.3.1 local 192.0.2.1
ip link set dev 6in4 up

ip -6 addr add 2001:db8:caf:1::2/127 dev 6in4
ip -6 route add ::/0 via 2001:db8:caf:1::1 dev 6in4

Les performances d'un tunnel vont dépendre de sa longueur. Pour éviter d'avoir des délais trop importants, il convient de configurer un tunnel vers le point IPv6 le plus proche.

=== Connectivité d'un site isolé : ''Tunnel Broker''===

La croissance du réseau IPv6 a commencé en s'appuyant sur l'infrastructure de communication de IPv4. Les premiers tunnels étaient configurés manuellement et pouvaient être très longs (et donc peu performants). La longueur d'un tunnel s'apprécie par le nombre de sauts IPv4 ou la distance qui sépare les 2 extrémités du tunnel. Pour des personnes non qualifiées, ceci reste complexe tant du point de vue technique que du point de vue du choix du point de sortie du tunnel. La constitution d'un tunnel a été simplifiée par l'introduction du ''Tunnel Broker'' [RFC 3053]. Les ''Tunnel Brokers'' représentent une méthode pour connecter un réseau IPv6 à l’internet v6. L'idée du ''Tunnel Broker'' consiste à mettre en œuvre une interaction de type "client/serveur". La partie cliente est localisée côté utilisateur tandis que la partie serveur traite les demandes de tunnels. Le modèle du ''Tunnel Broker'' est représenté par la figure 5.
<center>
[[image: 42-fig5-2.png |250px|thumb|center|Figure 5 : Modèle du ''Tunnel Broker''.]]
</center>

La création d'un tunnel à l'aide d'un ''Tunnel Broker'' fonctionne de la manière indiquée par la figure 6 ; à savoir :
# Une machine "double pile" du réseau IPv6 (typiquement un routeur) négocie avec le ''Tunnel Broker'' afin de s'authentifier et d'obtenir les informations de configuration du tunnel ainsi qu'un préfixe délégué.
# Le ''Tunnel Broker'' configure le serveur de tunnel retenu.
# Le ''Tunnel Broker'' envoie le script de configuration à la machine "double pile" coté utilisateur.
# Cette dernière, en exécutant le script reçu, crée le tunnel. Elle va ensuite encapsuler ses paquets IPv6 dans des paquets IPv4 à destination du serveur de tunnels, qui sert également de routeur. Ainsi, une communication en IPv6 peut s'effectuer entre des nœuds d'un réseau IPv6 isolé avec des nœuds de l'internet v6.

<center>
[[image:42-fig6-2.png |350px|thumb|center|Figure 6 : Configuration d'un ''Tunnel Broker'' avec TSP.]]
</center>

La négociation est opérée à l'aide du protocole TSP (''Tunnel Set Up Protocol'') [RFC 5572]. En l'absence de TSP, la demande de connexion au ''Tunnel Broker'' est réalisée par une interface web dont l'URL est connue à l'avance. Par cette interface, les paramètres nécessaires à l'établissement du tunnel entre le nœud de l'utilisateur et le serveur de tunnels sont récupérés. Le protocole de négociation TSP automatise cet échange. Plus précisément, TSP traite les paramètres suivants :
* l'authentification de l'utilisateur ;
* le type de tunnel :
** tunnel IPv6 sur IPv4 [RFC 4213],
** tunnel IPv4 sur IPv6 [RFC 2473],
** tunnel IPv6 sur UDP-IPv4 pour la traversée de NAT ;
* les adresses IPv4 pour les deux extrémités du tunnel ;
* l'adresse IPv6 assignée lorsque le client TSP est un terminal ;
* le préfixe IPv6 alloué lorsque le client TSP est un routeur.

TSP s'appuie sur l'échange de simples messages XML dont un exemple est donné ci-dessous. Cet exemple correspond à la demande de création d'un tunnel simple par un client TSP :

-- Successful TCP Connection --
C:VERSION=2.0.0 CR LF
S:CAPABILITY TUNNEL=V6V4 AUTH=ANONYMOUS CR LF
C:AUTHENTICATE ANONYMOUS CR LF
S:200 Authentication successful CR LF
C:Content-length: 123 CR LF
<tunnel action="create" type="v6v4">
<client>
<address type="ipv4">1.1.1.1</address>
</client>
</tunnel> CR LF
S: Content-length: 234 CR LF
200 OK CR LF
<tunnel action="info" type="v6v4" lifetime="1440">
<server>
<address type="ipv4">206.123.31.114</address>
<address type= "ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0000</address>
</server>
<client>
<address type="ipv4">1.1.1.1</address>
<address type= "ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
<address type="dn">userid.domain</address>
</client>
</tunnel> CR LF
C: Content-length: 35 CR LF
<tunnel action="accept"></tunnel> CR LF

La connectivité offerte par les ''Tunnel Brokers'' est en général fournie à titre provisoire (soit en attendant que l'offre des FAI soit disponible, soit pour faire des tests de validation, par exemple). Elle peut aussi être une première étape pour un prestataire de services pour procurer de la connectivité IPv6 à ses usagers.
Afin de promouvoir le passage à IPv6, les ''Tunnel Brokers'' sont souvent gratuits<ref>Linux Review. [http://en.linuxreviews.org/Free_IPv4_to_IPv6_Tunnel_Brokers Free IPv4 to IPv6 Tunnel Brokers]</ref>. Lorsque le ''Tunnel Broker'' a une faible répartition géographique de ses serveurs de tunnels, pour certains utilisateurs, la longueur des tunnels reste un problème.

== Tunnel automatique ==

Un tunnel configuré demande un travail de configuration pour chaque tunnel, ce qui peut être vu comme un inconvénient. Avec l'automatisation, l'intervention de l'administrateur est réduite à une phase de "configuration/initialisation" du service, à la place de celle de configuration des tunnels.
Ainsi, des solutions d'automatisation ont été étudiées, qui ont comme principe de contenir l'adresse IPv4 du tunnelier de destination dans l'adresse IPv6 de destination. Ce principe d'embarquer l'adresse du tunnelier dans l'adresse IPv6 au niveau du préfixe est présenté par le RFC 3056 et connu sous le nom de ''6to4''.
La figure 7 montre le cas d'application du tunnel automatique selon le principe ''6to4''. Il s'agit de relier un réseau IPv6 qui n'a pas de lien en IPv6 à l'internet IPv6. La connectivité va être effectuée au moyen d'un tunnel automatique à l'aide d'un réseau IPv4 auquel le réseau IPv6 est relié via un routeur en double pile. Ce routeur se situe en bordure des réseaux IPv4 et IPv6. On appellera un tel routeur, tunnelier (''Tunnel end point'').

<center>
[[Image:43-fig7-3.png|300px|thumb|center|Figure 7 : Cas d'application d'un tunnel automatique.]]
</center>

Comme pour ''6in4'', l'encapsulation des paquets IPv6 avec un tunnel automatique s'effectue dans les paquets IPv4. Par contre, au niveau de l'adressage, avec les tunnels automatiques, il faut définir un préfixe IPv6 spécifique qui indique qu'une adresse IPv4 est embarquée. La figure 8 illustre le mécanisme de construction d'un préfixe. Comme indiqué précédemment, le tunnelier se trouve en bordure du réseau. Il est connecté à la fois à l'internet v4 et à un réseau IPv6. C'est un nœud en double pile ; il possède obligatoirement une adresse IPv4 "unicast globale", comme <tt>192.0.2.1</tt> dans l'exemple. Retenons le préfixe spécifique '''<tt>2002::/16</tt>'''. Le préfixe du réseau IPv6 va être composé en concaténant le préfixe spécifique et l'adresse IPv4 "unicast globale" du tunnelier de ce réseau IPv6. Le préfixe du réseau IPv6 embarquant l'adresse IPv4 aura une longueur de 48 bits dans notre exemple et aura la valeur
<tt>2002:c000:201::/48</tt> (0xc0 = 192). Il est à noter qu'il a la même longueur que la partie publique d'un préfixe IPv6 GUA.

<center>
[[image:43-fig8-2-hd.png|300px|thumb|center|Figure 8 : Construction d'un préfixe IPv6 à partir de l'adresse IPv4 du tunnelier.]]
</center>

Aussi, comme le montre la figure 9, le préfixe de 48 bits laisse un champ SID de 16 bits pour numéroter des sous-réseaux ou liens dans le réseau IPv6. Il est alors possible d'attribuer des adresses au différents nœuds du réseau IPv6. Ils auront en commun d'avoir l'adresse IPv4 de leur tunnelier dans la partie préfixe de leur adresse.

<center>
[[image:43-fig6-hd.png|400px|thumb|center|Figure 9 : Format d'une adresse construite sur la base d'une connectivité par un tunnel.]]
</center>

La figure 10 présente l'envoi d'un paquet IPv6 de l'hôte A vers l'hôte B. Dans un premier temps, A interroge le DNS pour connaître l'adresse IPv6 de B. Dans notre exemple, la réponse est <tt>2002:c000:201:1::8051</tt>. Dans un second temps, l'hôte A émet le paquet vers cette destination. Ce paquet IPv6, dont l'adresse de destination commence par le préfixe <tt>2002::/16</tt>, est acheminé vers un tunnelier de l'internet v6. Lorsque le paquet est reçu par le tunnelier. Ce dernier analyse l'adresse IPv6 de destination et trouve l'adresse IPv4 de l'autre extrémité du tunnel (<tt>192.0.2.1</tt> dans l'exemple). Il effectue alors la transmission du paquet IPv6 en l'encapsulant dans un paquet IPv4. C'est cette encapsulation qui forme le tunnel. Le tunnelier du coté de B désencapsule le paquet IPv6 et le route normalement vers sa destination finale B en utilisant le routage interne.

<center>
[[image:43-fig10-3-hd.png|400px|thumb|center|Figure 10 : Envoi d'un paquet IPv6 en passant par un tunnel automatique.]]
</center>

Le principe des tunnels automatique de type ''6to4'' est intéressant en théorie mais en pratique, il reste le problème des tunneliers du coté de l'internet v6. En effet, à qui incombe la responsabilité d'installer ces tunneliers ? Une réponse a été le fournisseur d'accès à Internet pour ses clients. C'est dans ce contexte que la technique ''6rd'' a été proposée et que nous allons voir dans la section suivante.

=== Connectivité sur une infrastructure IPv4 : ''6rd'' ===

Le mécanisme ''6rd'' (''IPv6 Rapid Deployment''), proposé par le RFC 5569 après son déploiement par Free, a été étendu pour devenir un standard par le RFC 5969. ''6rd'' reprend le principe des tunnels automatiques du ''6to4'' en ciblant son application à un opérateur offrant une connectivité IPv6 et dont l'infrastructure repose sur IPv4. Cet opérateur peut être aussi bien public, comme un FAI, ou privé, comme une entreprise ou une administration.

L'idée de ''6rd'' porte sur l'utilisation d'un préfixe IPv6 propre à l'opérateur. Sa mise en oeuvre oblige l'opérateur à avoir le contrôle des 2 extrémités du tunneI. Autrement dit, il lui appartient d'installer un routeur de bordure connecté à l'internet v6. Il s'ensuit que les tunnels utilisés dans le contexte de ''6rd'' sont de longueur limitées à la taille du réseau IPv4 de l'opérateur. Il sont de fait court et ne sont pas sensés traverser l'internet. Les tunnels automatiques ''6rd'' ne servent qu'à passer la section IPv4 de l'opérateur. Avec ''6rd'', on se retrouve dans le cas classique où les routeurs internes (dont les tunneliers) traitent le trafic produit et destiné aux hôtes connectés à l'opérateur.
En fait, l'idée de ''6rd'' est de limiter la technique des tunnels automatiques pour un usage interne et local.

Dans la figure 11, qui schématise l'architecture de ''6rd'', le routeur de bordure est noté, selon la terminologie du RFC 5969, "''6rd'' BR"(''Border Relays''). Ce routeur est un tunnelier connecté en IPv4 du coté du l'infrastructure de communication de l'opérateur et connecté en IPv6 du coté de l'internet v6. Le réseau local IPv6 du coté de l'abonné est connecté à l'infrastructure de communication de l'opérateur à l'aide d'un tunnelier. Ce dernier appelé "''6rd'' CE" (''Customer Edge''), est également un routeur en "double pile". Concrètement, on le trouve sous la forme de la "box" dans l'installation des abonnés de l'opérateur. Chacun de ces tunneliers possèdent une adresse IPv4 sur l'interface réseau de l'infrastructure notée par exemple a4 pour le réseau local A. De manière similaire au principe utilisé dans ''6to4'', le préfixe IPv6 du réseau local est constitué en embarquant l'adresse IPv4 dans le préfixe IPv6 propre à cet opérateur noté <tt>pref6rd</tt>. Le préfixe IPv6 du réseau local est noté dans la figure 11 pour le réseau A <tt>pref6rd:a4::</tt>.
La figure 12 montre que la connectivité en IPv6 peut être établie entre 2 hôtes par un tunnel entre 2 ''box'' ou entre une box et le routeur de bordure afin qu'un hôte puisse accéder à l'internet v6. Dans les deux cas, un tunnel automatique est établi pour passer l'infrastructure de communication centrale fonctionnant en IPv4.

<center>
[[Image:43-fig12a-hd.png|350px|thumb|center|Figure 11 : Architecture de ''6rd''.]]
</center>

Le format de l’adresse IPv6 ''6rd'' dérive d'un préfixe <tt>2000::/3</tt> pris dans le plan d'adressage global unicast (''GUA''). Il utilise le préfixe propre alloué au FAI par son registre régional (RIR). Il devient difficile de différencier un trafic sortant d’un réseau ''6rd'' d’un trafic IPv6 natif car les deux partagent le même préfixe. Le préfixe IPv6 du domaine de l'opérateur est complété par tout ou partie de l'adresse IPv4 alloué au ''6rd'' CE", pour former le préfixe ''6rd''. Le "''6rd'' CE" est l'extrémité du tunnel coté client (dans la figure 11) et connue comme la box fournie par le FAI. L'adresse IPv4 du routeur "''6rd'' CE" est normalement publique, mais ce n’est pas obligatoire. L’organisation de l’adresse IPv6 est décrite par la figure 13. À noter que, au sein d'un même opérateur, si les adresses IPv4 s'agrègent sur un préfixe commun, il n'est pas nécessaire d'encoder la totalité des 32 bits de l'adresse IPv4 dans le préfixe IPv6 ; ce qui libère des bits pour laisser une numérotation des liens internes (SID) au réseau IPv6 à connecter. Il est laissé le soin à chaque opérateur de définir le nombre de bits de l'adresse IPv4 à conserver. La seule contrainte est que le préfixe réseau ne doit pas dépasser 64 bits autrement dit n + i + s bits = 64 bits
<center>
[[Image:43-fig13-hd.png|400px|thumb|center|Figure 12 : Format d'une adresse ''6rd''.]]
</center>

Pour illustrer la figure 12, considérons tout d’abord que l’adresse IPv4 <tt>192.0.2.129</tt> (c000:281 en hexadécimal) a été attribuée à l’interface du"''6rd'' CE" du réseau local A de la figure 11. L'opérateur dispose du préfixe IPv6 <tt>2001:db8::/32</tt> pour son domaine ''6rd''. Les adresses de tous les "''6rd'' CE" s'agrègent sur le préfixe <tt>192.0.0.0/8</tt>. L'opérateur peut garder 24 bits comme partie significative. Les 24 bits de poids faible de l'adresse IPv4 suffisent, en effet, à distinguer chacun des "''6rd'' CE" de son réseau. Les 8 bits du préfixe IPv4 (valeur décimale 192 dans notre exemple) peuvent être omis. Le préfixe IPv6 de chaque "''6rd'' CE" aura donc une longueur de 56 bits, correspondant à l'addition du préfixe du domaine (32 bits) avec la partie significative de l'adresse IPv4 (24 bits). Dans le cas de l'exemple, la figure 13 illustre cet assemblage entre le préfixe de l'opérateur et l'adresse IPv4. Pour plus de lisibilité, la partie significative de l'adresse IPv4 a été laissée en notation décimale pointée sur la figure. En notation de l'adresse IPv6, le ''6rd delegated prefix'' pour le "''6rd'' CE" d'adresse <tt>192.0.2.129</tt> sera <tt>2001:db8:2:8100::/56</tt>. Il restera alors 8 bits, au titre du SID (''Subnet Identifier''), pour la numérotation des sous-réseaux internes du réseau connecté par le "''6rd'' CE". À l’extérieur de l'opérateur, les adresses IPv6 apparaîtront comme des adresses IPv6 natives. À l'intérieur de l'opérateur, les adresses seront interprétées pour établir un tunnel entre les routeurs de bordures de l'infrastructure IPv4 de l'opérateur.

<center>
[[Image:43-fig14-hd.png|400px|thumb|center|Figure 13 : Exemple de construction d'un préfixe délégué ''6rd''.]]
</center>

Le transfert avec la technique ''6rd'' s'organise selon 3 cas :

* transfert inter-réseau IPv6 local. La figure 12 illustre ce cas lorsque les 2 hôtes souhaitent communiquer. La source de préfixe "pref6rd:a4" envoie un paquet IPv6 à destination de l'hôte de préfixe "pref6rd:b4". Le paquet IPv6 arrive en mode natif au "''6rd'' CE" de la source. Si l’adresse IPv6 de destination est incluse dans le préfixe du domaine ''6rd'' configuré localement, il sera transmis directement à l'autre "''6rd'' CE" comme c'est le cas ici. Les adresses IPv4 des "''6rd'' CE" sont extraites des adresses IPv6 pour constituer le tunnel. Le paquet IPv4, d'adresse source "a4" et d'adresse destination "b4", encapsule le paquet IPv6. Ce paquet IPv4 est acheminé au "''6rd'' CE" de destination par l'infrastructure IPv4 de l'opérateur. Le routeur "''6rd'' CE" de destination reçoit le paquet IPv4. Il vérifie, par mesure de sécurité, que l'adresse source de l'en-tête IPv4 correspond à celle intégrée dans l'adresse IPv6 source. Il désencapsule le paquet IPv6 et le transmet sur le réseau local pour son acheminement à la destination IPv6 ;
* transfert du réseau local IPv6 vers l'internet v6. Le trafic IPv6 est reçu en mode natif sur le "''6rd'' CE". L'adresse de destination IPv6 ne correspond pas à un préfixe IPv6 du domaine de l'opérateur, ce qui signifie que la destination est extérieure au domaine de ''6rd'' local. Dans ce cas, le paquet IPv6 doit être transmis à un routeur de bordure ''6rd''. Comme dans le cas du transfert inter-site, le paquet IPv6 est encapsulé dans un paquet IPv4. Cependant, la différence est que l'adresse IPv4 du routeur de bordure est obtenue dans la table de routage du "''6rd'' CE". Le routeur de bordure reçoit le paquet IPv4 et supprime l'encapsulation IPv4. Après le contrôle de sécurité, le paquet IPv6 est transmis sur l'internet v6 ;
* transfert de l'internet v6 vers le site. Si un routeur de bordure reçoit un paquet IPv6 à destination d’une adresse IPv4 incluse dans le préfixe ''6rd'' du domaine, il transmet le paquet au routeur "''6rd'' CE" correspondant en utilisant le même principe que le cas précédent. Dans le cas du trafic retour, d'un flux initialisé par une machine ''6rd'', comme l'adresse de destination est issue du préfixe global de l'opérateur, la voie retour passera par le même relais. Ainsi, la communication s'effectuera en empruntant la même route à l'aller et au retour.

La technique ''6rd'' est adaptée à une mise en œuvre locale d’IPv6 pour un opérateur dont l'infrastructure interne fonctionne encore en IPv4<ref>Cisco. (2011). White paper. [http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/whitepaper_c11-665758.html IPv6 Rapid Deployment: Provide IPv6 Access to Customers over an IPv4-Only Network]</ref>. Cette technique de tunnel répond à des questions de fiabilité et de délai. Comme le relais avec l'internet v6 est administré par, et pour, l'opérateur lui-même, le service de connectivité peut être de bonne qualité. En cas de défaillance, la responsabilité de l'opérateur est directement engagée.

== Conclusion==

Dans la démarche d'intégration d'IPv6, la meilleure solution est d'utiliser IPv6 nativement, comme IPv4. La complexité supplémentaire induite par les tunnels, ainsi que la réduction de la MTU qu'ils imposent (entraînant des problèmes de connectivité "épisodiques") sont épargnées. Mais il n'est pas toujours possible de maintenir la connectivité IPv6 ou de trouver un opérateur offrant la connectivité IPv6. Alors, dans ces situations, il faut se résoudre à utiliser des tunnels. Le RFC 7059 effectue un inventaire des techniques d'intégration reposant sur des tunnels. Toutes les techniques ne se valent pas du point de vue des performances et de la fiabilité. Les meilleures techniques sont celles qui établissent des tunnels locaux ou de courte distance et pour lesquelles les extrémités du tunnel sont gérées et offrent un service contractuel. Le choix d'une technique de tunnel doit se faire en fonction des besoins de connectivité du réseau dans lequel IPv6 doit être intégré.

Nous avons présenté, dans cette activité, les techniques les plus intéressantes pour établir une connectivité IPv6. Le ''tunnel broker'' représente une méthode pour tirer un simple tunnel entre un réseau IPv6 isolé et un point d'entrée de l'internet v6. Les techniques ''6to4'' et ''6rd'' utilisent des tunnels automatiques au sein du réseau IPv4 d'une organisation. Si le principe de tunnel automatique de ''6to4'' est pertinent, sa mise en œuvre a été problématique. La dépréciation récente du préfixe anycast réservé à son usage entraîne, de fait, son déclin. La variante ''6rd'', en corrigeant les défauts de ''6to4'', se positionne comme une alternative.

''6rd'' repose sur l'encapsulation directe : le paquet IPv6 est placé directement dans un paquet IPv4. Ce mode d'encapsulation ne traverse pas les NAT car les NAT ont, pour la plupart, la capacité de traiter uniquement les protocoles de transport TCP et UDP. La technique de tunnel Teredo [RFC 4380] traite ce problème en encapsulant les paquets IPv6 dans UDP puis dans IPv4. Il a été reporté par l'article<ref>Huston, G. (2011). The ISP Column. [http://www.potaroo.net/ispcol/2011-04/teredo.html Testing Teredo]</ref> des performances et une fiabilité du service de connectivité de très mauvaise qualité. Cette solution comme ''6to4'' ont négligé la mise en oeuvre opérationnelle et ne sont plus utilisées de nos jours.

Pour conclure, nous rappelons la règle habituelle de connectivité d'IPv6 qui dit : « double-pile où tu peux, tunnel où tu dois » (''Dual stack where you can; tunnel where you must''). La double-pile (IPv4 et IPv6 sur tous les équipements) est la solution la plus simple pour la gestion du réseau. Le tunnel est plus fragile et fait dépendre IPv6 d'IPv4. Il sert dans les situations où des routeurs antédiluviens ne peuvent être mis à jour pour traiter des paquets IPv6. Le tunnel est solution d'attente avant le remplacement par un équipement moderne.

==Références bibliographiques==
<references />

== Pour aller plus loin ==

RFC et leur analyse par S. Bortzmeyer :
* RFC 2473 Generic Packet Tunneling in IPv6 Specification
* RFC 3053 IPv6 Tunnel Broker
* RFC 3056 Connection of IPv6 Domains via IPv4 Clouds
* RFC 3068 An Anycast Prefix for 6to4 Relay Routers
* RFC 4213 Basic IPv6 Transition Mechanisms [http://www.bortzmeyer.org/4213.html Analyse]
* RFC 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
* RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [http://www.bortzmeyer.org/5569.html Analyse]
* RFC 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) [http://www.bortzmeyer.org/5572.html Analyse]
* RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [http://www.bortzmeyer.org/5969.html Analyse]
* RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]
* RFC 6343 Advisory Guidelines for 6to4 Deployment
* RFC 6782 Wireline Incremental IPv6 [http://www.bortzmeyer.org/6782.html Analyse]
* RFC 7059 A Comparison of IPv6 over IPv4 Tunnel Mechanisms [http://www.bortzmeyer.org/7059.html Analyse]
* RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]
* RFC 7526 Deprecating Anycast Prefix for 6to4 Relay Routers [http://www.bortzmeyer.org/7526.html Analyse]

MOOC:Corrections s8

2023-01-09T03:29:05Z

Panelli:

Remplacer les QCM à réponses multiples par des systèmes de questions à réponse simple (ex: Ajouter une proposition vraie et ajouter une proposition "toutes les propositions sont vraies")

== Seq0 ==
A02Q04 : "adresse IP" => "adresse IP publique"

Doc compagnon A02 : Donner une définition de datagramme

== Seq1 ==
A11E01 : Revoir le calcul (prise en compte des années bissextiles)
''20221212; JL : remplacement des valeurs calculées sur la base de 365,25 jours/an au lieu de 365 dans la version précédente''

A12E02 : Rappeler (doc compagnon ou dans indice) que l'IID peut être nul.

''20221212; JL : Dans l'indice il est déjà indiqué qu' "il n'y a pas d'adresse réservée dans un sous-réseau".
Ajout au doc compagnon d'un nota au paragraphe "Identification locale : l'IID (Interface IDentifier)" de l'activité A14''

Bien indiquer dans le doc compagnon qu'il n'y a pas d'adresse de broadcast

''20221212; JL : Act13, les passages concernés sont à présent en "gras".
(cf ''définition du multicast'' et ''explication groupe réservé 1, adresse <tt>ff02::1</tt>)''

Doc compagnon : expliquer les conséquences d'un subnet au delà des 64 bits ?
''20221213; JL : Ajout d'un "hors texte" au parargraphe "Préfixes de sous-réseaux (SID Subnet IDentifier)"
du doc compagnon de l'activité A14.
Doc Compagnon A13 :
* Donner des exemples de construction des adresses multicast sollicité, afin de rendre plus facile la question A13E04.
''20221214; JL : Ajout d'un exemple affichant les adresses LLA et ULA de l'interface eth0 de l'hôte cos
et les adresses multicast sur lesquelles l'interface est à l'écoute''
* Attention une redondance dans le doc compagnon sur le multicast sollicité entre le chapitre A13 et son annexe
''20221214; JL : redondances supprimées dans l'annexe et renvoi au paragraphe "Structure de l'adresse multicast" pour le format général.''
* L'exemple pour l'adresse multicast Embedded-RP du point de rendez-vous est 2001:660:3307:125::3 alors qu'à la page suivante on indique son préfixe comme étant 2001:660:3007:125/64 et l'adresse multicast dérivée ff7x:340:2001:660:3007:125:aabb:ccdd. Le 3 de 3307 du point de rendez-vous ne devrait-il pas être un 0?
''20221214; JL : corrigé''
* Aussi, dans cette section, le format pour les identifiants de groupe aabb:ccdd peut laisser croire que les deux symboles hexadécimaux qui composent un octet doivent être les mêmes, alors qu'il s'agit uniquement de marques de positions des quartets. Ça peut perturber les lecteurs qui ne sont pas familiers avec l'hexadécimal et qui pourraient penser que 11aa:77ee est un identifiant de groupe valide alors que 12ab:78ef ne l'est pas.
''20221214; JL : corrigé''

Vidéo A13 partie 1 : Au niveau du cours A13 partie 1 à la minute 7:00, le fd de l'adresse locale unique est représenté 11110001 en binaire au lieu de 11111101
'''''TODO'''''

Doc Compagnon A14 :
* donner un exemple de construction de l'IID à partir de l'adresse MAC
''20230106; JL reformulation de certaines parties du paragraphe et ajout d'un exemple extrait de la commande <tt>ifconfig</tt>''
* nouvelle structure pour les adresses multicast IPv6 ? (RFC3306 et 7371)
'''''TODO'''''
* Donner un pointeur vers une calculette subnet (exemple : https://fr.rakko.tools/tools/27/)
''20230106; JL : Ajout d'une rubrique "Ressources complémentaires" précédant la rubrique "Pour aller plus loin" avec le pointeur sur la calculatrice CIDR. Ajout d'un hors texte au paragraphe "Représentation des subdivisions" renvoyant à la cette ressource.''
* Etendre la mise en oeuvre pour Windows. J'ai lu la page 63. Il faudrait la modifier pour utiliser la terminologie Microsoft :
** Adresse IPv6 de type "Public" pour les flux entrants,
** Adresse IPv6 de type "Temporaire" pour les flux sortants.
''20230106; JL : réécriture du paragraphe "Valeur temporaire aléatoire". "Public" est ambigu (quid des contextes privatifs ULA) j'ai utlisé "adresse principale" pour les flux entrants (en renvoyant sur le paragraphe IID opaque stable). J'ai conservé l'illustration de l'antique windows XP qui reste valide et cohérente relativement au nouveau contenu du paragraphe.''

Toutes deux ont un IID généré pseudo-aléatoirement.
Cette ressource est plus claire il me semble : https://www.networkacademy.io/ccna/ipv6/ipv6-on-windows
''20230106; JL :Ajout de cette URL dans les références bibliographiques''

== Seq2 ==

Exercice A24 : Remplacer l'extension RH0 par une extension de fragmentation
''20230104; BS : création d'un nouvel exercice portant sur la fragmentation. Cf mail de Bruno pour validation''
Refaire A23 : QUIZ DOCUMENT COMPAGNON (car doublon) pour les questions
A23Q6
A23Q7
A23Q8

== Seq3 ==

S3E02 : Reformuler la question ?

TP A36 : l'étape 1 contient déjà des configurations, revoir le sujet ?

== Seq4 ==
Doc compagnon A42 / Tunnel configuré : revoir l'adressage des points d'entrée de tunnel (/64 ou /127 ?)

Questions A44 : Attention à l'acronyme ALG :
* A44Q01 : "Application Level Gateway"
* A44Q06 : "Application Layer Gateway"

''20230109; PAN : Retenue Application Level Gateway dans le cours et le doc compagnon"

MOOC:Compagnon Act44-s7

2023-01-09T03:17:53Z

Panelli: /* Conclusion */

__NOTOC__
=<div id="ALG">Activité 44 : Interopérer des applications par passerelles applicatives </div>=


== Contexte d'utilisation des passerelles applicatives ==

Il n'existe pas une solution magique à tous les problèmes. Le déploiement bien trop lent d'IPv6 a laissé une situation peu satisfaisante face au manque d'adresses IPv4. La migration vers IPv6 ne pourra pas se faire sans la traduction. Comme nous l'avons vu, la traduction au niveau réseau à l'aide de NAT64 est un dispositif qui vise à faciliter le déploiement des clients IPv6, tout en étant aussi utilisable pour rendre les serveurs IPv4 accessibles à l'Internet v6. Si NAT64 est une solution fonctionnelle pour la communication avec des systèmes IPv4, le retour d'expérience rapporté par les RFC 6586 et RFC 7269 montre que certaines applications ne fonctionnent plus lorsque leurs communications passent par un NAT64. C'est par exemple le cas de la signalisation de la téléphonie : les adresses IP sont transmises dans la signalisation, et ne sont pas traduites par NAT64. Lorsque l'utilisation de NAT64 conduit à une situation d'échec, le recours à une passerelle applicative constitue une alternative pour les applications dont l'installation d'un relais intermédiaire est possible.

Outre la résolution de certains défauts de fonctionnement, la solution de la passerelle applicative offre une technique d'interopérabilité moins intrusive que NAT64 au niveau de l'infrastructure de communication. En effet, déployer NAT64 demande de modifier le routage et d'allouer des adresses. Le déploiement du NAT64 est transparent pour les hôtes mais nécessite des modifications au niveau de l'infrastructure de communication. Dans le cas du déploiement d'une passerelle applicative, nous sommes dans une situation inverse. Les modifications sont à apporter uniquement dans la configuration des hôtes : installation de la passerelle, mais aussi du client qui, dans certains cas, doit être configuré pour déléguer ses requêtes à la passerelle, à l'instar du navigateur web dont on configure la référence du proxy par exemple. Ainsi, il est possible, avec une passerelle applicative, d'avoir un déploiement progressif d'IPv6 dans le réseau, sans perturber les services en place. Dans le cadre d'une infrastructure de communication en production, cette caractéristique peut être appréciée.

Enfin, dans le cas d'un client IPv4 qui se connecte à des serveurs de l'Internet v6, la passerelle applicative est de nos jours la seule méthode d'interopérabilité. Mais il est vrai que ce scénario n'est pas encore d'actualité au vu de l'état du déploiement de l'Internet v6. Nous allons détailler, dans la suite de cette activité, les scénarios d'utilisation de ce dispositif dans le cas d'un client IPv6 avec un serveur IPv4.

== Principe des passerelles applicatives ==

Les passerelles applicatives, ou ALG (''Application Layer Gateway''), représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure 1) configurées pour accéder aux deux versions du protocole. Les clients IPv6 émettent leurs requêtes vers la passerelle applicative comme s'ils s'adressaient directement au service. La passerelle interprète le contenu de ces requêtes pour les retransmettre ensuite en IPv4 à destination du service concerné.

<center>
[[image:44-fig1-2.png|500px|thumb|center|Figure 1 : Communication par passerelle applicative.]]
</center>

Une ou plusieurs passerelles peuvent être installées en fonction des services rendus disponibles sur le réseau (par exemple : serveur d'impression, serveur de messagerie, web, etc.). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces passerelles.

L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les passerelles applicatives. Certains protocoles ne sont pas prévus pour intégrer un relais intermédiaire (par exemple ''telnet''). D'autres protocoles, par leur nature propriétaire, ne permettent pas le développement de passerelles par une tierce partie si celle-ci n'est pas disponible (comme par exemple ''Skype''). Mais, comme la liste suivante l'indique, les ALG concernent des applications courantes qui représentent une proportion importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.
Les passerelles applicatives regroupent :
* les ''proxies'' et les caches web ;
* les ''spoolers'' d'impression ;
* les serveurs de courrier électronique ;
* les serveurs DNS ;
* ...

== Cas du service Web ==

Il s'agit ici de faire communiquer des clients avec des services Web ; client et serveur utilisant une version différente du protocole IP. La passerelle applicative utilisée dans ce cas est un relais HTTP qui va interpréter les requêtes des clients pour les retransmettre vers le serveur Web. Deux modèles de déploiement existent pour ce type de relais :
* le déploiement d'un serveur mandataire (''proxy'') dans le réseau des clients, leur permettant d'atteindre les serveurs extérieurs, dont ceux qui n'utilisent pas la même version du protocole IP ;
* le déploiement d'un relais inverse (''reverse proxy'') dans le réseau du serveur, permettant d'accepter les requêtes des clients qui n'utilisent pas la même version du protocole IP que le serveur.

=== ALG placée du coté du client ===

Le relais HTTP est ici localisé dans le réseau des clients, généralement dans la DMZ du site ou sur le routeur domestique, comme le montre la figure 2. Les clients sont configurés pour utiliser cette passerelle en tant que serveur mandataire afin d'atteindre les services Web extérieurs. Ce type de déploiement est couramment utilisé pour sécuriser les clients d'accès Web vers des sites malveillants.

Afin de permettre l'interopérabilité entre les différentes versions du protocole IP, la passerelle est connectée et configurée sur un réseau "double pile". Si, par exemple, les clients sont sur un réseau seulement IPv6, l'adresse IPv6 de la passerelle leur est indiquée en tant que serveur mandataire. La passerelle recevra alors les requêtes HTTP de ces clients et les relaiera vers les services demandées en IPv4 ou en IPv6 selon le protocole utilisé par le serveur.

<center>
[[image:45-Fig2-hd.png|400px|thumb|center|Figure 2 : Exemple de passerelle applicative placée du coté client.]]
</center>

Le listing suivant donne un extrait de la configuration d'un serveur Apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.

#cat /usr/local/etc/apache/httpd.conf
#
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
<IfModule mod_proxy.c>
ProxyRequests On
<Directory proxy:*>
Order deny,allow
Allow from all
</Directory>
#
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server ver.;"Block" removes all outgoing Via: headers)
# Set to one of: Off | On | Full | Block
#
ProxyVia On
</IfModule>
# End of proxy directives.

=== ALG placée du coté du service ===
La problématique ici à résoudre est de rendre un service Web accessible avec les deux versions du protocole IP alors que celui-ci n'en utilise qu'une seule. S'ajoute à cette problématique la contrainte opérationnelle du service : le fonctionnement du site Web sera-t-il perturbé par l'intégration d'IPv6 ? L'expérience utilisateur des visiteurs va-t-elle être impactée ?

Pour rendre accessible un service Web en IPv6, la solution la plus simple consiste à activer la connectivité IPv6 sur le réseau où est connecté ce service, ainsi que sur la machine qui l'héberge. Mais cette solution pose un ensemble de problèmes opérationnels car l'infrastructure d'hébergement d'un site Web peut être assez complexe (système d'équilibrage de charge ou ''load balancers'', cache, etc.). Une réelle étude du passage à IPv6 de cette infrastructure peut être nécessaire pour effectuer une transition pérenne. Le RFC 6589 s'intéresse à cette problématique et délivre un ensemble de conseils pour les hébergeurs qui veulent rendre leurs serveurs accessibles en IPv6.

==== Déploiement d'un relais inverse ====

Une solution moins coûteuse et plus rapide à mettre en œuvre (mais avec bien sûr quelques limitations) consiste à déployer un relais inverse (''reverse-proxy'') proche du serveur, comme montré par la figure 3. Le rôle de ce relais est d'accepter les requêtes vers le service Web utilisant la version du protocole qui n'est pas encore déployée sur le serveur. Les clients envoient leur requête au relais de manière transparente, comme s'il s'agissait du service. Le relais se charge, pour le client, de transférer les requêtes vers le serveur et de recevoir sa réponse en utilisant le protocole IP déployé sur le serveur.

<center>
[[image:45-Fig3-hd.png|400px|thumb|center|Figure 3 : Exemple de passerelle applicative placée du coté serveur.]]
</center>

Dans la mise en œuvre du relais inverse, une étape importante consiste en la configuration du DNS. En effet, l'adresse du relais doit être renseignée comme l'un des enregistrements pour le service concerné. Ainsi, par exemple, pour un service seulement accessible en IPv4, l'adresse IPv6 du relais sera renseignée comme enregistrement AAAA au même niveau que l'enregistrement A de l'adresse du serveur.

Le listing suivant donne un extrait de la configuration d'un relais inverse opéré par le logiciel [https://fr.wikipedia.org/wiki/Nginx nginx]. La configuration consiste à indiquer le renvoi des requêtes Web reçues en IPv6 vers le serveur resté joignable en IPv4.

#cat /etc/nginx/sites-available/default
...
location / {
proxy_pass http://192.0.2.1/;
}

Dans le contexte initial, le service Web n'est accessible qu'en IPv4. L'adresse IPv4 du service (notée S4) est enregistrée dans le DNS. Celle-ci est récupérée par les clients à partir du nom du service afin d'initier une connexion directe vers le serveur, comme montrée dans la figure 4.

<center>
[[Image:45-Fig4-hd.png|300px|thumb|center|Figure 4 : Accès direct pour les clients IPv4.]]
</center>

Le scénario d'intégration d'IPv6 par un relais inverse pour un service Web passe par deux actions, comme représenté par la figure 5 :
* la mise en place d'un relais inverse dans l'infrastructure du service, sur un réseau "double pile" ;
* l'enregistrement de l'adresse IPv6 du relais (notée S6) comme l'adresse IPv6 officielle du serveur.
Un client possédant une connectivité IPv6 et souhaitant consulter le service va résoudre le nom du service en deux adresses : une IPv4 et une IPv6. La préférence à IPv6 du navigateur lui fera utiliser en priorité cette adresse. Sa requête se fera alors de manière transparente à destination du ''reverse proxy'' comme indiqué par la figure 5.

<center>
[[Image:45-Fig5-hd2.png|300px|thumb|center|Figure 5 : Accès par le relais inverse pour les clients IPv6.]]
</center>

Le relais inverse propose donc une solution simple pour assurer une interopérabilité de son service Web avec IPv6. Cependant, elle n'est pas adaptée à des sites à large audience. Même largement dimensionné, un unique relais ne pourrait pas absorber la portion IPv6 des requêtes, même si celle-ci est encore en dessous des 10 %. De plus, le relais constitue un point de faiblesse unique (SPOF, ''Single Point of Failure'') pouvant compromettre l'accès au service.

==== Utilisation d'un service d'hébergement ou de distribution des contenus ====
Pour ces sites à large audience, plusieurs solutions peuvent être envisagées pour permettre l'interopérabilité avec IPv6 [RFC 6883] :
* migrer son infrastructure d'hébergement en "double pile" (comme mentionné plus haut, cette solution est la plus complexe) ;
* faire appel à un service d'hébergement offrant une connectivité "double pile" ;
* continuer à héberger son service en IPv4, mais utiliser un réseau de distribution de contenus (CDN, ''Content Delivery Network'') "double pile".

Les deux dernières solutions permettent au responsable du service de déléguer la complexité de l'intégration et de la gestion d'IPv6 à un prestataire extérieur. Ces services sont aujourd'hui assez répandus. Les hébergeurs de sites Web offrent maintenant couramment un accès "double pile" aux services hébergés, que ce soit sur des offres de serveurs mutualisés ou dédiés. Toutes les prestations d'hébergement des acteurs majeurs en France que sont OVH, Gandi ou Online, intègrent IPv6 dans leurs offres.

Les réseaux de distribution de contenus (ou CDN) ont pour objectif de répliquer le contenu du service en différents points stratégiques du réseau, permettant aux utilisateurs d'accéder plus rapidement au service et à l'infrastructure du service d'être soulagée d'une partie du trafic. Les CDN peuvent, de plus, permettre l'interopérabilité avec IPv6 en jouant le même rôle que le relais inverse vu précédemment, avec bien sûr une infrastructure plus robuste. Des services de CDN comme Akamai, CloudFlare ou Cedexis permettent ainsi d'offrir des contenus en IPv6 alors que ceux-ci sont hébergés sur des services seulement IPv4.

== Conclusion ==

{{HorsTexte|Passage à l'échelle|Le passage à l'échelle, dans ce contexte, signifie une croissance de la taille, soit en nombre de clients du service applicatif, soit en terme de volume de flux. La mise en place d'une passerelle applicative ajoute un relais protocolaire dans la chaîne de communication entre le client et le serveur applicatif. Bien que ce relais puisse être fonctionnel et transparent, la montée en charge peut poser problème. La capacité du relais étant finie et limitée, il peut introduire des défauts à partir d'un certain nombre de clients ou d'une certaine quantité de trafic.}}
Les passerelles applicatives offrent un moyen simple d'interopération entre des clients et des serveurs qui n'utilisent pas la même version du protocole IP. Parce qu'elles interprètent le contenu du paquet dans la couche d'application, elles sont transparentes pour l'infrastructure de communications (routeurs). Elles ne demandent pas de modifications au niveau du réseau. Cependant, les passerelles applicatives posent des contraintes qui limitent leur usage, telles que :
* introduction d'un délai pour le traitement des paquets ;
* difficultés à passer le facteur d'échelle, et possibilité de congestion ;
* applications non conçues pour fonctionner avec un relais intermédiaire.

En effet, des protocoles propriétaires ainsi que certains protocoles assurant la confidentialité des communications peuvent rendre impossible la mise en œuvre d'un tel dispositif (pour un protocole de sécurité, une telle passerelle pourrait s'apparenter à un "homme au milieu"). De plus, selon le protocole utilisé, la mise en œuvre d'une telle passerelle peut s'avérer complexe. Par exemple, le protocole SIP nécessite une interprétation de l'ensemble de la signalisation. Enfin, une passerelle applicative n'est pas forcément le meilleur choix si le protocole applicatif embarque des adresses IP.


== Pour aller plus loin ==
RFC et leur analyse par S. Bortzmeyer
* RFC 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]
* RFC 6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation
* RFC 6586 Experiences from an IPv6-Only Network [http://www.bortzmeyer.org/6586.html Analyse]
* RFC 6589 Considerations for Transitioning Content to IPv6 [http://www.bortzmeyer.org/6589.html Analyse]
* RFC 6883 IPv6 Guidance for Internet Content Providers and Application Service Providers [http://www.bortzmeyer.org/6883.html Analyse]
* RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269.html Analyse]

MOOC:Compagnon Act44-s7

2023-01-09T03:16:56Z

Panelli: /* Activité 44 : Interopérer des applications par passerelles applicatives */

__NOTOC__
=<div id="ALG">Activité 44 : Interopérer des applications par passerelles applicatives </div>=


== Contexte d'utilisation des passerelles applicatives ==

Il n'existe pas une solution magique à tous les problèmes. Le déploiement bien trop lent d'IPv6 a laissé une situation peu satisfaisante face au manque d'adresses IPv4. La migration vers IPv6 ne pourra pas se faire sans la traduction. Comme nous l'avons vu, la traduction au niveau réseau à l'aide de NAT64 est un dispositif qui vise à faciliter le déploiement des clients IPv6, tout en étant aussi utilisable pour rendre les serveurs IPv4 accessibles à l'Internet v6. Si NAT64 est une solution fonctionnelle pour la communication avec des systèmes IPv4, le retour d'expérience rapporté par les RFC 6586 et RFC 7269 montre que certaines applications ne fonctionnent plus lorsque leurs communications passent par un NAT64. C'est par exemple le cas de la signalisation de la téléphonie : les adresses IP sont transmises dans la signalisation, et ne sont pas traduites par NAT64. Lorsque l'utilisation de NAT64 conduit à une situation d'échec, le recours à une passerelle applicative constitue une alternative pour les applications dont l'installation d'un relais intermédiaire est possible.

Outre la résolution de certains défauts de fonctionnement, la solution de la passerelle applicative offre une technique d'interopérabilité moins intrusive que NAT64 au niveau de l'infrastructure de communication. En effet, déployer NAT64 demande de modifier le routage et d'allouer des adresses. Le déploiement du NAT64 est transparent pour les hôtes mais nécessite des modifications au niveau de l'infrastructure de communication. Dans le cas du déploiement d'une passerelle applicative, nous sommes dans une situation inverse. Les modifications sont à apporter uniquement dans la configuration des hôtes : installation de la passerelle, mais aussi du client qui, dans certains cas, doit être configuré pour déléguer ses requêtes à la passerelle, à l'instar du navigateur web dont on configure la référence du proxy par exemple. Ainsi, il est possible, avec une passerelle applicative, d'avoir un déploiement progressif d'IPv6 dans le réseau, sans perturber les services en place. Dans le cadre d'une infrastructure de communication en production, cette caractéristique peut être appréciée.

Enfin, dans le cas d'un client IPv4 qui se connecte à des serveurs de l'Internet v6, la passerelle applicative est de nos jours la seule méthode d'interopérabilité. Mais il est vrai que ce scénario n'est pas encore d'actualité au vu de l'état du déploiement de l'Internet v6. Nous allons détailler, dans la suite de cette activité, les scénarios d'utilisation de ce dispositif dans le cas d'un client IPv6 avec un serveur IPv4.

== Principe des passerelles applicatives ==

Les passerelles applicatives, ou ALG (''Application Layer Gateway''), représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure 1) configurées pour accéder aux deux versions du protocole. Les clients IPv6 émettent leurs requêtes vers la passerelle applicative comme s'ils s'adressaient directement au service. La passerelle interprète le contenu de ces requêtes pour les retransmettre ensuite en IPv4 à destination du service concerné.

<center>
[[image:44-fig1-2.png|500px|thumb|center|Figure 1 : Communication par passerelle applicative.]]
</center>

Une ou plusieurs passerelles peuvent être installées en fonction des services rendus disponibles sur le réseau (par exemple : serveur d'impression, serveur de messagerie, web, etc.). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces passerelles.

L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les passerelles applicatives. Certains protocoles ne sont pas prévus pour intégrer un relais intermédiaire (par exemple ''telnet''). D'autres protocoles, par leur nature propriétaire, ne permettent pas le développement de passerelles par une tierce partie si celle-ci n'est pas disponible (comme par exemple ''Skype''). Mais, comme la liste suivante l'indique, les ALG concernent des applications courantes qui représentent une proportion importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.
Les passerelles applicatives regroupent :
* les ''proxies'' et les caches web ;
* les ''spoolers'' d'impression ;
* les serveurs de courrier électronique ;
* les serveurs DNS ;
* ...

== Cas du service Web ==

Il s'agit ici de faire communiquer des clients avec des services Web ; client et serveur utilisant une version différente du protocole IP. La passerelle applicative utilisée dans ce cas est un relais HTTP qui va interpréter les requêtes des clients pour les retransmettre vers le serveur Web. Deux modèles de déploiement existent pour ce type de relais :
* le déploiement d'un serveur mandataire (''proxy'') dans le réseau des clients, leur permettant d'atteindre les serveurs extérieurs, dont ceux qui n'utilisent pas la même version du protocole IP ;
* le déploiement d'un relais inverse (''reverse proxy'') dans le réseau du serveur, permettant d'accepter les requêtes des clients qui n'utilisent pas la même version du protocole IP que le serveur.

=== ALG placée du coté du client ===

Le relais HTTP est ici localisé dans le réseau des clients, généralement dans la DMZ du site ou sur le routeur domestique, comme le montre la figure 2. Les clients sont configurés pour utiliser cette passerelle en tant que serveur mandataire afin d'atteindre les services Web extérieurs. Ce type de déploiement est couramment utilisé pour sécuriser les clients d'accès Web vers des sites malveillants.

Afin de permettre l'interopérabilité entre les différentes versions du protocole IP, la passerelle est connectée et configurée sur un réseau "double pile". Si, par exemple, les clients sont sur un réseau seulement IPv6, l'adresse IPv6 de la passerelle leur est indiquée en tant que serveur mandataire. La passerelle recevra alors les requêtes HTTP de ces clients et les relaiera vers les services demandées en IPv4 ou en IPv6 selon le protocole utilisé par le serveur.

<center>
[[image:45-Fig2-hd.png|400px|thumb|center|Figure 2 : Exemple de passerelle applicative placée du coté client.]]
</center>

Le listing suivant donne un extrait de la configuration d'un serveur Apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.

#cat /usr/local/etc/apache/httpd.conf
#
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
<IfModule mod_proxy.c>
ProxyRequests On
<Directory proxy:*>
Order deny,allow
Allow from all
</Directory>
#
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server ver.;"Block" removes all outgoing Via: headers)
# Set to one of: Off | On | Full | Block
#
ProxyVia On
</IfModule>
# End of proxy directives.

=== ALG placée du coté du service ===
La problématique ici à résoudre est de rendre un service Web accessible avec les deux versions du protocole IP alors que celui-ci n'en utilise qu'une seule. S'ajoute à cette problématique la contrainte opérationnelle du service : le fonctionnement du site Web sera-t-il perturbé par l'intégration d'IPv6 ? L'expérience utilisateur des visiteurs va-t-elle être impactée ?

Pour rendre accessible un service Web en IPv6, la solution la plus simple consiste à activer la connectivité IPv6 sur le réseau où est connecté ce service, ainsi que sur la machine qui l'héberge. Mais cette solution pose un ensemble de problèmes opérationnels car l'infrastructure d'hébergement d'un site Web peut être assez complexe (système d'équilibrage de charge ou ''load balancers'', cache, etc.). Une réelle étude du passage à IPv6 de cette infrastructure peut être nécessaire pour effectuer une transition pérenne. Le RFC 6589 s'intéresse à cette problématique et délivre un ensemble de conseils pour les hébergeurs qui veulent rendre leurs serveurs accessibles en IPv6.

==== Déploiement d'un relais inverse ====

Une solution moins coûteuse et plus rapide à mettre en œuvre (mais avec bien sûr quelques limitations) consiste à déployer un relais inverse (''reverse-proxy'') proche du serveur, comme montré par la figure 3. Le rôle de ce relais est d'accepter les requêtes vers le service Web utilisant la version du protocole qui n'est pas encore déployée sur le serveur. Les clients envoient leur requête au relais de manière transparente, comme s'il s'agissait du service. Le relais se charge, pour le client, de transférer les requêtes vers le serveur et de recevoir sa réponse en utilisant le protocole IP déployé sur le serveur.

<center>
[[image:45-Fig3-hd.png|400px|thumb|center|Figure 3 : Exemple de passerelle applicative placée du coté serveur.]]
</center>

Dans la mise en œuvre du relais inverse, une étape importante consiste en la configuration du DNS. En effet, l'adresse du relais doit être renseignée comme l'un des enregistrements pour le service concerné. Ainsi, par exemple, pour un service seulement accessible en IPv4, l'adresse IPv6 du relais sera renseignée comme enregistrement AAAA au même niveau que l'enregistrement A de l'adresse du serveur.

Le listing suivant donne un extrait de la configuration d'un relais inverse opéré par le logiciel [https://fr.wikipedia.org/wiki/Nginx nginx]. La configuration consiste à indiquer le renvoi des requêtes Web reçues en IPv6 vers le serveur resté joignable en IPv4.

#cat /etc/nginx/sites-available/default
...
location / {
proxy_pass http://192.0.2.1/;
}

Dans le contexte initial, le service Web n'est accessible qu'en IPv4. L'adresse IPv4 du service (notée S4) est enregistrée dans le DNS. Celle-ci est récupérée par les clients à partir du nom du service afin d'initier une connexion directe vers le serveur, comme montrée dans la figure 4.

<center>
[[Image:45-Fig4-hd.png|300px|thumb|center|Figure 4 : Accès direct pour les clients IPv4.]]
</center>

Le scénario d'intégration d'IPv6 par un relais inverse pour un service Web passe par deux actions, comme représenté par la figure 5 :
* la mise en place d'un relais inverse dans l'infrastructure du service, sur un réseau "double pile" ;
* l'enregistrement de l'adresse IPv6 du relais (notée S6) comme l'adresse IPv6 officielle du serveur.
Un client possédant une connectivité IPv6 et souhaitant consulter le service va résoudre le nom du service en deux adresses : une IPv4 et une IPv6. La préférence à IPv6 du navigateur lui fera utiliser en priorité cette adresse. Sa requête se fera alors de manière transparente à destination du ''reverse proxy'' comme indiqué par la figure 5.

<center>
[[Image:45-Fig5-hd2.png|300px|thumb|center|Figure 5 : Accès par le relais inverse pour les clients IPv6.]]
</center>

Le relais inverse propose donc une solution simple pour assurer une interopérabilité de son service Web avec IPv6. Cependant, elle n'est pas adaptée à des sites à large audience. Même largement dimensionné, un unique relais ne pourrait pas absorber la portion IPv6 des requêtes, même si celle-ci est encore en dessous des 10 %. De plus, le relais constitue un point de faiblesse unique (SPOF, ''Single Point of Failure'') pouvant compromettre l'accès au service.

==== Utilisation d'un service d'hébergement ou de distribution des contenus ====
Pour ces sites à large audience, plusieurs solutions peuvent être envisagées pour permettre l'interopérabilité avec IPv6 [RFC 6883] :
* migrer son infrastructure d'hébergement en "double pile" (comme mentionné plus haut, cette solution est la plus complexe) ;
* faire appel à un service d'hébergement offrant une connectivité "double pile" ;
* continuer à héberger son service en IPv4, mais utiliser un réseau de distribution de contenus (CDN, ''Content Delivery Network'') "double pile".

Les deux dernières solutions permettent au responsable du service de déléguer la complexité de l'intégration et de la gestion d'IPv6 à un prestataire extérieur. Ces services sont aujourd'hui assez répandus. Les hébergeurs de sites Web offrent maintenant couramment un accès "double pile" aux services hébergés, que ce soit sur des offres de serveurs mutualisés ou dédiés. Toutes les prestations d'hébergement des acteurs majeurs en France que sont OVH, Gandi ou Online, intègrent IPv6 dans leurs offres.

Les réseaux de distribution de contenus (ou CDN) ont pour objectif de répliquer le contenu du service en différents points stratégiques du réseau, permettant aux utilisateurs d'accéder plus rapidement au service et à l'infrastructure du service d'être soulagée d'une partie du trafic. Les CDN peuvent, de plus, permettre l'interopérabilité avec IPv6 en jouant le même rôle que le relais inverse vu précédemment, avec bien sûr une infrastructure plus robuste. Des services de CDN comme Akamai, CloudFlare ou Cedexis permettent ainsi d'offrir des contenus en IPv6 alors que ceux-ci sont hébergés sur des services seulement IPv4.

== Conclusion ==

Les passerelles applicatives offrent un moyen simple d'interopération entre des clients et des serveurs qui n'utilisent pas la même version du protocole IP. Parce qu'elles interprètent le contenu du paquet dans la couche d'application, elles sont transparentes pour l'infrastructure de communications (routeurs). Elles ne demandent pas de modifications au niveau du réseau. Cependant, les passerelles applicatives posent des contraintes qui limitent leur usage, telles que :
* introduction d'un délai pour le traitement des paquets ;
* difficultés à passer le facteur d'échelle, et possibilité de congestion ;
* applications non conçues pour fonctionner avec un relais intermédiaire.
{{HorsTexte|Passage à l'échelle|Le passage à l'échelle, dans ce contexte, signifie une croissance de la taille, soit en nombre de clients du service applicatif, soit en terme de volume de flux. La mise en place d'une passerelle applicative ajoute un relais protocolaire dans la chaîne de communication entre le client et le serveur applicatif. Bien que ce relais puisse être fonctionnel et transparent, la montée en charge peut poser problème. La capacité du relais étant finie et limitée, il peut introduire des défauts à partir d'un certain nombre de clients ou d'une certaine quantité de trafic.}}

En effet, des protocoles propriétaires ainsi que certains protocoles assurant la confidentialité des communications peuvent rendre impossible la mise en œuvre d'un tel dispositif (pour un protocole de sécurité, une telle passerelle pourrait s'apparenter à un "homme au milieu"). De plus, selon le protocole utilisé, la mise en œuvre d'une telle passerelle peut s'avérer complexe. Par exemple, le protocole SIP nécessite une interprétation de l'ensemble de la signalisation. Enfin, une passerelle applicative n'est pas forcément le meilleur choix si le protocole applicatif embarque des adresses IP.


== Pour aller plus loin ==
RFC et leur analyse par S. Bortzmeyer
* RFC 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]
* RFC 6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation
* RFC 6586 Experiences from an IPv6-Only Network [http://www.bortzmeyer.org/6586.html Analyse]
* RFC 6589 Considerations for Transitioning Content to IPv6 [http://www.bortzmeyer.org/6589.html Analyse]
* RFC 6883 IPv6 Guidance for Internet Content Providers and Application Service Providers [http://www.bortzmeyer.org/6883.html Analyse]
* RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269.html Analyse]

MOOC:Compagnon Act44-s7

2023-01-09T03:16:03Z

Panelli: /* Conclusion */

__NOTOC__
=<div id="ALG">Activité 44 : Interopérer des applications par passerelles applicatives </div>=


== Contexte d'utilisation des passerelles applicatives ==

Il n'existe pas une solution magique à tous les problèmes. Le déploiement bien trop lent d'IPv6 a laissé une situation peu satisfaisante face au manque d'adresses IPv4. La migration vers IPv6 ne pourra pas se faire sans la traduction. Comme nous l'avons vu, la traduction au niveau réseau à l'aide de NAT64 est un dispositif qui vise à faciliter le déploiement des clients IPv6, tout en étant aussi utilisable pour rendre les serveurs IPv4 accessibles à l'Internet v6. Si NAT64 est une solution fonctionnelle pour la communication avec des systèmes IPv4, le retour d'expérience rapporté par les RFC 6586 et RFC 7269 montre que certaines applications ne fonctionnent plus lorsque leurs communications passent par un NAT64. C'est par exemple le cas de la signalisation de la téléphonie : les adresses IP sont transmises dans la signalisation, et ne sont pas traduites par NAT64. Lorsque l'utilisation de NAT64 conduit à une situation d'échec, le recours à une passerelle applicative constitue une alternative pour les applications dont l'installation d'un relais intermédiaire est possible.

Outre la résolution de certains défauts de fonctionnement, la solution de la passerelle applicative offre une technique d'interopérabilité moins intrusive que NAT64 au niveau de l'infrastructure de communication. En effet, déployer NAT64 demande de modifier le routage et d'allouer des adresses. Le déploiement du NAT64 est transparent pour les hôtes mais nécessite des modifications au niveau de l'infrastructure de communication. Dans le cas du déploiement d'une passerelle applicative, nous sommes dans une situation inverse. Les modifications sont à apporter uniquement dans la configuration des hôtes : installation de la passerelle, mais aussi du client qui, dans certains cas, doit être configuré pour déléguer ses requêtes à la passerelle, à l'instar du navigateur web dont on configure la référence du proxy par exemple. Ainsi, il est possible, avec une passerelle applicative, d'avoir un déploiement progressif d'IPv6 dans le réseau, sans perturber les services en place. Dans le cadre d'une infrastructure de communication en production, cette caractéristique peut être appréciée.

Enfin, dans le cas d'un client IPv4 qui se connecte à des serveurs de l'Internet v6, la passerelle applicative est de nos jours la seule méthode d'interopérabilité. Mais il est vrai que ce scénario n'est pas encore d'actualité au vu de l'état du déploiement de l'Internet v6. Nous allons détailler, dans la suite de cette activité, les scénarios d'utilisation de ce dispositif dans le cas d'un client IPv6 avec un serveur IPv4.

== Principe des passerelles applicatives ==

Les passerelles applicatives, ou ALG (''Application Layer Gateway''), représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure 1) configurées pour accéder aux deux versions du protocole. Les clients IPv6 émettent leurs requêtes vers la passerelle applicative comme s'ils s'adressaient directement au service. La passerelle interprète le contenu de ces requêtes pour les retransmettre ensuite en IPv4 à destination du service concerné.

<center>
[[image:44-fig1-2.png|500px|thumb|center|Figure 1 : Communication par passerelle applicative.]]
</center>

Une ou plusieurs passerelles peuvent être installées en fonction des services rendus disponibles sur le réseau (par exemple : serveur d'impression, serveur de messagerie, web, etc.). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces passerelles.

L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les passerelles applicatives. Certains protocoles ne sont pas prévus pour intégrer un relais intermédiaire (par exemple ''telnet''). D'autres protocoles, par leur nature propriétaire, ne permettent pas le développement de passerelles par une tierce partie si celle-ci n'est pas disponible (comme par exemple ''Skype''). Mais, comme la liste suivante l'indique, les ALG concernent des applications courantes qui représentent une proportion importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.
Les passerelles applicatives regroupent :
* les ''proxies'' et les caches web ;
* les ''spoolers'' d'impression ;
* les serveurs de courrier électronique ;
* les serveurs DNS ;
* ...

== Cas du service Web ==

Il s'agit ici de faire communiquer des clients avec des services Web ; client et serveur utilisant une version différente du protocole IP. La passerelle applicative utilisée dans ce cas est un relais HTTP qui va interpréter les requêtes des clients pour les retransmettre vers le serveur Web. Deux modèles de déploiement existent pour ce type de relais :
* le déploiement d'un serveur mandataire (''proxy'') dans le réseau des clients, leur permettant d'atteindre les serveurs extérieurs, dont ceux qui n'utilisent pas la même version du protocole IP ;
* le déploiement d'un relais inverse (''reverse proxy'') dans le réseau du serveur, permettant d'accepter les requêtes des clients qui n'utilisent pas la même version du protocole IP que le serveur.

=== ALG placée du coté du client ===

Le relais HTTP est ici localisé dans le réseau des clients, généralement dans la DMZ du site ou sur le routeur domestique, comme le montre la figure 2. Les clients sont configurés pour utiliser cette passerelle en tant que serveur mandataire afin d'atteindre les services Web extérieurs. Ce type de déploiement est couramment utilisé pour sécuriser les clients d'accès Web vers des sites malveillants.

Afin de permettre l'interopérabilité entre les différentes versions du protocole IP, la passerelle est connectée et configurée sur un réseau "double pile". Si, par exemple, les clients sont sur un réseau seulement IPv6, l'adresse IPv6 de la passerelle leur est indiquée en tant que serveur mandataire. La passerelle recevra alors les requêtes HTTP de ces clients et les relaiera vers les services demandées en IPv4 ou en IPv6 selon le protocole utilisé par le serveur.

<center>
[[image:45-Fig2-hd.png|400px|thumb|center|Figure 2 : Exemple de passerelle applicative placée du coté client.]]
</center>

Le listing suivant donne un extrait de la configuration d'un serveur Apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.

#cat /usr/local/etc/apache/httpd.conf
#
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
<IfModule mod_proxy.c>
ProxyRequests On
<Directory proxy:*>
Order deny,allow
Allow from all
</Directory>
#
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server ver.;"Block" removes all outgoing Via: headers)
# Set to one of: Off | On | Full | Block
#
ProxyVia On
</IfModule>
# End of proxy directives.

=== ALG placée du coté du service ===
La problématique ici à résoudre est de rendre un service Web accessible avec les deux versions du protocole IP alors que celui-ci n'en utilise qu'une seule. S'ajoute à cette problématique la contrainte opérationnelle du service : le fonctionnement du site Web sera-t-il perturbé par l'intégration d'IPv6 ? L'expérience utilisateur des visiteurs va-t-elle être impactée ?

Pour rendre accessible un service Web en IPv6, la solution la plus simple consiste à activer la connectivité IPv6 sur le réseau où est connecté ce service, ainsi que sur la machine qui l'héberge. Mais cette solution pose un ensemble de problèmes opérationnels car l'infrastructure d'hébergement d'un site Web peut être assez complexe (système d'équilibrage de charge ou ''load balancers'', cache, etc.). Une réelle étude du passage à IPv6 de cette infrastructure peut être nécessaire pour effectuer une transition pérenne. Le RFC 6589 s'intéresse à cette problématique et délivre un ensemble de conseils pour les hébergeurs qui veulent rendre leurs serveurs accessibles en IPv6.

==== Déploiement d'un relais inverse ====

Une solution moins coûteuse et plus rapide à mettre en œuvre (mais avec bien sûr quelques limitations) consiste à déployer un relais inverse (''reverse-proxy'') proche du serveur, comme montré par la figure 3. Le rôle de ce relais est d'accepter les requêtes vers le service Web utilisant la version du protocole qui n'est pas encore déployée sur le serveur. Les clients envoient leur requête au relais de manière transparente, comme s'il s'agissait du service. Le relais se charge, pour le client, de transférer les requêtes vers le serveur et de recevoir sa réponse en utilisant le protocole IP déployé sur le serveur.

<center>
[[image:45-Fig3-hd.png|400px|thumb|center|Figure 3 : Exemple de passerelle applicative placée du coté serveur.]]
</center>

Dans la mise en œuvre du relais inverse, une étape importante consiste en la configuration du DNS. En effet, l'adresse du relais doit être renseignée comme l'un des enregistrements pour le service concerné. Ainsi, par exemple, pour un service seulement accessible en IPv4, l'adresse IPv6 du relais sera renseignée comme enregistrement AAAA au même niveau que l'enregistrement A de l'adresse du serveur.

Le listing suivant donne un extrait de la configuration d'un relais inverse opéré par le logiciel [https://fr.wikipedia.org/wiki/Nginx nginx]. La configuration consiste à indiquer le renvoi des requêtes Web reçues en IPv6 vers le serveur resté joignable en IPv4.

#cat /etc/nginx/sites-available/default
...
location / {
proxy_pass http://192.0.2.1/;
}

Dans le contexte initial, le service Web n'est accessible qu'en IPv4. L'adresse IPv4 du service (notée S4) est enregistrée dans le DNS. Celle-ci est récupérée par les clients à partir du nom du service afin d'initier une connexion directe vers le serveur, comme montrée dans la figure 4.

<center>
[[Image:45-Fig4-hd.png|300px|thumb|center|Figure 4 : Accès direct pour les clients IPv4.]]
</center>

Le scénario d'intégration d'IPv6 par un relais inverse pour un service Web passe par deux actions, comme représenté par la figure 5 :
* la mise en place d'un relais inverse dans l'infrastructure du service, sur un réseau "double pile" ;
* l'enregistrement de l'adresse IPv6 du relais (notée S6) comme l'adresse IPv6 officielle du serveur.
Un client possédant une connectivité IPv6 et souhaitant consulter le service va résoudre le nom du service en deux adresses : une IPv4 et une IPv6. La préférence à IPv6 du navigateur lui fera utiliser en priorité cette adresse. Sa requête se fera alors de manière transparente à destination du ''reverse proxy'' comme indiqué par la figure 5.

<center>
[[Image:45-Fig5-hd2.png|300px|thumb|center|Figure 5 : Accès par le relais inverse pour les clients IPv6.]]
</center>

Le relais inverse propose donc une solution simple pour assurer une interopérabilité de son service Web avec IPv6. Cependant, elle n'est pas adaptée à des sites à large audience. Même largement dimensionné, un unique relais ne pourrait pas absorber la portion IPv6 des requêtes, même si celle-ci est encore en dessous des 10 %. De plus, le relais constitue un point de faiblesse unique (SPOF, ''Single Point of Failure'') pouvant compromettre l'accès au service.

==== Utilisation d'un service d'hébergement ou de distribution des contenus ====
Pour ces sites à large audience, plusieurs solutions peuvent être envisagées pour permettre l'interopérabilité avec IPv6 [RFC 6883] :
* migrer son infrastructure d'hébergement en "double pile" (comme mentionné plus haut, cette solution est la plus complexe) ;
* faire appel à un service d'hébergement offrant une connectivité "double pile" ;
* continuer à héberger son service en IPv4, mais utiliser un réseau de distribution de contenus (CDN, ''Content Delivery Network'') "double pile".

Les deux dernières solutions permettent au responsable du service de déléguer la complexité de l'intégration et de la gestion d'IPv6 à un prestataire extérieur. Ces services sont aujourd'hui assez répandus. Les hébergeurs de sites Web offrent maintenant couramment un accès "double pile" aux services hébergés, que ce soit sur des offres de serveurs mutualisés ou dédiés. Toutes les prestations d'hébergement des acteurs majeurs en France que sont OVH, Gandi ou Online, intègrent IPv6 dans leurs offres.

Les réseaux de distribution de contenus (ou CDN) ont pour objectif de répliquer le contenu du service en différents points stratégiques du réseau, permettant aux utilisateurs d'accéder plus rapidement au service et à l'infrastructure du service d'être soulagée d'une partie du trafic. Les CDN peuvent, de plus, permettre l'interopérabilité avec IPv6 en jouant le même rôle que le relais inverse vu précédemment, avec bien sûr une infrastructure plus robuste. Des services de CDN comme Akamai, CloudFlare ou Cedexis permettent ainsi d'offrir des contenus en IPv6 alors que ceux-ci sont hébergés sur des services seulement IPv4.

== Conclusion ==

Les passerelles applicatives offrent un moyen simple d'interopération entre des clients et des serveurs qui n'utilisent pas la même version du protocole IP. Parce qu'elles interprètent le contenu du paquet dans la couche d'application, elles sont transparentes pour l'infrastructure de communications (routeurs). Elles ne demandent pas de modifications au niveau du réseau. Cependant, les passerelles applicatives posent des contraintes qui limitent leur usage, telles que :
* introduction d'un délai pour le traitement des paquets ;
* difficultés à passer le facteur d'échelle, et possibilité de congestion ;
* applications non conçues pour fonctionner avec un relais intermédiaire.
{{HorsTexte|Passage à l'échelle|Le passage à l'échelle, dans ce contexte, signifie une croissance de la taille, soit en nombre de clients du service applicatif, soit en terme de volume de flux. La mise en place d'une passerelle applicative ajoute un relais protocolaire dans la chaîne de communication entre le client et le serveur applicatif. Bien que ce relais puisse être fonctionnel et transparent, la montée en charge peut poser problème. La capacité du relais étant finie et limitée, il peut introduire des défauts à partir d'un certain nombre de clients ou d'une certaine quantité de trafic.}}

En effet, des protocoles propriétaires ainsi que certains protocoles assurant la confidentialité des communications peuvent rendre impossible la mise en œuvre d'un tel dispositif (pour un protocole de sécurité, une telle passerelle pourrait s'apparenter à un "homme au milieu"). De plus, selon le protocole utilisé, la mise en œuvre d'une telle passerelle peut s'avérer complexe. Par exemple, le protocole SIP nécessite une interprétation de l'ensemble de la signalisation. Enfin, une passerelle applicative n'est pas forcément le meilleur choix si le protocole applicatif embarque des adresses IP.

== Références bibliographiques ==
<references />

== Pour aller plus loin ==
RFC et leur analyse par S. Bortzmeyer
* RFC 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]
* RFC 6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation
* RFC 6586 Experiences from an IPv6-Only Network [http://www.bortzmeyer.org/6586.html Analyse]
* RFC 6589 Considerations for Transitioning Content to IPv6 [http://www.bortzmeyer.org/6589.html Analyse]
* RFC 6883 IPv6 Guidance for Internet Content Providers and Application Service Providers [http://www.bortzmeyer.org/6883.html Analyse]
* RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269.html Analyse]

MOOC:Compagnon Act44-s7

2023-01-09T03:14:22Z

Panelli: /* Principe des passerelles applicatives */

__NOTOC__
=<div id="ALG">Activité 44 : Interopérer des applications par passerelles applicatives </div>=


== Contexte d'utilisation des passerelles applicatives ==

Il n'existe pas une solution magique à tous les problèmes. Le déploiement bien trop lent d'IPv6 a laissé une situation peu satisfaisante face au manque d'adresses IPv4. La migration vers IPv6 ne pourra pas se faire sans la traduction. Comme nous l'avons vu, la traduction au niveau réseau à l'aide de NAT64 est un dispositif qui vise à faciliter le déploiement des clients IPv6, tout en étant aussi utilisable pour rendre les serveurs IPv4 accessibles à l'Internet v6. Si NAT64 est une solution fonctionnelle pour la communication avec des systèmes IPv4, le retour d'expérience rapporté par les RFC 6586 et RFC 7269 montre que certaines applications ne fonctionnent plus lorsque leurs communications passent par un NAT64. C'est par exemple le cas de la signalisation de la téléphonie : les adresses IP sont transmises dans la signalisation, et ne sont pas traduites par NAT64. Lorsque l'utilisation de NAT64 conduit à une situation d'échec, le recours à une passerelle applicative constitue une alternative pour les applications dont l'installation d'un relais intermédiaire est possible.

Outre la résolution de certains défauts de fonctionnement, la solution de la passerelle applicative offre une technique d'interopérabilité moins intrusive que NAT64 au niveau de l'infrastructure de communication. En effet, déployer NAT64 demande de modifier le routage et d'allouer des adresses. Le déploiement du NAT64 est transparent pour les hôtes mais nécessite des modifications au niveau de l'infrastructure de communication. Dans le cas du déploiement d'une passerelle applicative, nous sommes dans une situation inverse. Les modifications sont à apporter uniquement dans la configuration des hôtes : installation de la passerelle, mais aussi du client qui, dans certains cas, doit être configuré pour déléguer ses requêtes à la passerelle, à l'instar du navigateur web dont on configure la référence du proxy par exemple. Ainsi, il est possible, avec une passerelle applicative, d'avoir un déploiement progressif d'IPv6 dans le réseau, sans perturber les services en place. Dans le cadre d'une infrastructure de communication en production, cette caractéristique peut être appréciée.

Enfin, dans le cas d'un client IPv4 qui se connecte à des serveurs de l'Internet v6, la passerelle applicative est de nos jours la seule méthode d'interopérabilité. Mais il est vrai que ce scénario n'est pas encore d'actualité au vu de l'état du déploiement de l'Internet v6. Nous allons détailler, dans la suite de cette activité, les scénarios d'utilisation de ce dispositif dans le cas d'un client IPv6 avec un serveur IPv4.

== Principe des passerelles applicatives ==

Les passerelles applicatives, ou ALG (''Application Layer Gateway''), représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure 1) configurées pour accéder aux deux versions du protocole. Les clients IPv6 émettent leurs requêtes vers la passerelle applicative comme s'ils s'adressaient directement au service. La passerelle interprète le contenu de ces requêtes pour les retransmettre ensuite en IPv4 à destination du service concerné.

<center>
[[image:44-fig1-2.png|500px|thumb|center|Figure 1 : Communication par passerelle applicative.]]
</center>

Une ou plusieurs passerelles peuvent être installées en fonction des services rendus disponibles sur le réseau (par exemple : serveur d'impression, serveur de messagerie, web, etc.). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces passerelles.

L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les passerelles applicatives. Certains protocoles ne sont pas prévus pour intégrer un relais intermédiaire (par exemple ''telnet''). D'autres protocoles, par leur nature propriétaire, ne permettent pas le développement de passerelles par une tierce partie si celle-ci n'est pas disponible (comme par exemple ''Skype''). Mais, comme la liste suivante l'indique, les ALG concernent des applications courantes qui représentent une proportion importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.
Les passerelles applicatives regroupent :
* les ''proxies'' et les caches web ;
* les ''spoolers'' d'impression ;
* les serveurs de courrier électronique ;
* les serveurs DNS ;
* ...

== Cas du service Web ==

Il s'agit ici de faire communiquer des clients avec des services Web ; client et serveur utilisant une version différente du protocole IP. La passerelle applicative utilisée dans ce cas est un relais HTTP qui va interpréter les requêtes des clients pour les retransmettre vers le serveur Web. Deux modèles de déploiement existent pour ce type de relais :
* le déploiement d'un serveur mandataire (''proxy'') dans le réseau des clients, leur permettant d'atteindre les serveurs extérieurs, dont ceux qui n'utilisent pas la même version du protocole IP ;
* le déploiement d'un relais inverse (''reverse proxy'') dans le réseau du serveur, permettant d'accepter les requêtes des clients qui n'utilisent pas la même version du protocole IP que le serveur.

=== ALG placée du coté du client ===

Le relais HTTP est ici localisé dans le réseau des clients, généralement dans la DMZ du site ou sur le routeur domestique, comme le montre la figure 2. Les clients sont configurés pour utiliser cette passerelle en tant que serveur mandataire afin d'atteindre les services Web extérieurs. Ce type de déploiement est couramment utilisé pour sécuriser les clients d'accès Web vers des sites malveillants.

Afin de permettre l'interopérabilité entre les différentes versions du protocole IP, la passerelle est connectée et configurée sur un réseau "double pile". Si, par exemple, les clients sont sur un réseau seulement IPv6, l'adresse IPv6 de la passerelle leur est indiquée en tant que serveur mandataire. La passerelle recevra alors les requêtes HTTP de ces clients et les relaiera vers les services demandées en IPv4 ou en IPv6 selon le protocole utilisé par le serveur.

<center>
[[image:45-Fig2-hd.png|400px|thumb|center|Figure 2 : Exemple de passerelle applicative placée du coté client.]]
</center>

Le listing suivant donne un extrait de la configuration d'un serveur Apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.

#cat /usr/local/etc/apache/httpd.conf
#
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
<IfModule mod_proxy.c>
ProxyRequests On
<Directory proxy:*>
Order deny,allow
Allow from all
</Directory>
#
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server ver.;"Block" removes all outgoing Via: headers)
# Set to one of: Off | On | Full | Block
#
ProxyVia On
</IfModule>
# End of proxy directives.

=== ALG placée du coté du service ===
La problématique ici à résoudre est de rendre un service Web accessible avec les deux versions du protocole IP alors que celui-ci n'en utilise qu'une seule. S'ajoute à cette problématique la contrainte opérationnelle du service : le fonctionnement du site Web sera-t-il perturbé par l'intégration d'IPv6 ? L'expérience utilisateur des visiteurs va-t-elle être impactée ?

Pour rendre accessible un service Web en IPv6, la solution la plus simple consiste à activer la connectivité IPv6 sur le réseau où est connecté ce service, ainsi que sur la machine qui l'héberge. Mais cette solution pose un ensemble de problèmes opérationnels car l'infrastructure d'hébergement d'un site Web peut être assez complexe (système d'équilibrage de charge ou ''load balancers'', cache, etc.). Une réelle étude du passage à IPv6 de cette infrastructure peut être nécessaire pour effectuer une transition pérenne. Le RFC 6589 s'intéresse à cette problématique et délivre un ensemble de conseils pour les hébergeurs qui veulent rendre leurs serveurs accessibles en IPv6.

==== Déploiement d'un relais inverse ====

Une solution moins coûteuse et plus rapide à mettre en œuvre (mais avec bien sûr quelques limitations) consiste à déployer un relais inverse (''reverse-proxy'') proche du serveur, comme montré par la figure 3. Le rôle de ce relais est d'accepter les requêtes vers le service Web utilisant la version du protocole qui n'est pas encore déployée sur le serveur. Les clients envoient leur requête au relais de manière transparente, comme s'il s'agissait du service. Le relais se charge, pour le client, de transférer les requêtes vers le serveur et de recevoir sa réponse en utilisant le protocole IP déployé sur le serveur.

<center>
[[image:45-Fig3-hd.png|400px|thumb|center|Figure 3 : Exemple de passerelle applicative placée du coté serveur.]]
</center>

Dans la mise en œuvre du relais inverse, une étape importante consiste en la configuration du DNS. En effet, l'adresse du relais doit être renseignée comme l'un des enregistrements pour le service concerné. Ainsi, par exemple, pour un service seulement accessible en IPv4, l'adresse IPv6 du relais sera renseignée comme enregistrement AAAA au même niveau que l'enregistrement A de l'adresse du serveur.

Le listing suivant donne un extrait de la configuration d'un relais inverse opéré par le logiciel [https://fr.wikipedia.org/wiki/Nginx nginx]. La configuration consiste à indiquer le renvoi des requêtes Web reçues en IPv6 vers le serveur resté joignable en IPv4.

#cat /etc/nginx/sites-available/default
...
location / {
proxy_pass http://192.0.2.1/;
}

Dans le contexte initial, le service Web n'est accessible qu'en IPv4. L'adresse IPv4 du service (notée S4) est enregistrée dans le DNS. Celle-ci est récupérée par les clients à partir du nom du service afin d'initier une connexion directe vers le serveur, comme montrée dans la figure 4.

<center>
[[Image:45-Fig4-hd.png|300px|thumb|center|Figure 4 : Accès direct pour les clients IPv4.]]
</center>

Le scénario d'intégration d'IPv6 par un relais inverse pour un service Web passe par deux actions, comme représenté par la figure 5 :
* la mise en place d'un relais inverse dans l'infrastructure du service, sur un réseau "double pile" ;
* l'enregistrement de l'adresse IPv6 du relais (notée S6) comme l'adresse IPv6 officielle du serveur.
Un client possédant une connectivité IPv6 et souhaitant consulter le service va résoudre le nom du service en deux adresses : une IPv4 et une IPv6. La préférence à IPv6 du navigateur lui fera utiliser en priorité cette adresse. Sa requête se fera alors de manière transparente à destination du ''reverse proxy'' comme indiqué par la figure 5.

<center>
[[Image:45-Fig5-hd2.png|300px|thumb|center|Figure 5 : Accès par le relais inverse pour les clients IPv6.]]
</center>

Le relais inverse propose donc une solution simple pour assurer une interopérabilité de son service Web avec IPv6. Cependant, elle n'est pas adaptée à des sites à large audience. Même largement dimensionné, un unique relais ne pourrait pas absorber la portion IPv6 des requêtes, même si celle-ci est encore en dessous des 10 %. De plus, le relais constitue un point de faiblesse unique (SPOF, ''Single Point of Failure'') pouvant compromettre l'accès au service.

==== Utilisation d'un service d'hébergement ou de distribution des contenus ====
Pour ces sites à large audience, plusieurs solutions peuvent être envisagées pour permettre l'interopérabilité avec IPv6 [RFC 6883] :
* migrer son infrastructure d'hébergement en "double pile" (comme mentionné plus haut, cette solution est la plus complexe) ;
* faire appel à un service d'hébergement offrant une connectivité "double pile" ;
* continuer à héberger son service en IPv4, mais utiliser un réseau de distribution de contenus (CDN, ''Content Delivery Network'') "double pile".

Les deux dernières solutions permettent au responsable du service de déléguer la complexité de l'intégration et de la gestion d'IPv6 à un prestataire extérieur. Ces services sont aujourd'hui assez répandus. Les hébergeurs de sites Web offrent maintenant couramment un accès "double pile" aux services hébergés, que ce soit sur des offres de serveurs mutualisés ou dédiés. Toutes les prestations d'hébergement des acteurs majeurs en France que sont OVH, Gandi ou Online, intègrent IPv6 dans leurs offres.

Les réseaux de distribution de contenus (ou CDN) ont pour objectif de répliquer le contenu du service en différents points stratégiques du réseau, permettant aux utilisateurs d'accéder plus rapidement au service et à l'infrastructure du service d'être soulagée d'une partie du trafic. Les CDN peuvent, de plus, permettre l'interopérabilité avec IPv6 en jouant le même rôle que le relais inverse vu précédemment, avec bien sûr une infrastructure plus robuste. Des services de CDN comme Akamai, CloudFlare ou Cedexis permettent ainsi d'offrir des contenus en IPv6 alors que ceux-ci sont hébergés sur des services seulement IPv4.

== Conclusion ==

Les passerelles applicatives offrent un moyen simple d'interopération entre des clients et des serveurs qui n'utilisent pas la même version du protocole IP. Parce qu'elles interprètent le contenu du paquet dans la couche d'application, elles sont transparentes pour l'infrastructure de communications (routeurs). Elles ne demandent pas de modifications au niveau du réseau. Cependant, les passerelles applicatives posent des contraintes qui limitent leur usage<ref>IPv6.com. (2008). Tech spotlight. [http://ipv6.com/articles/gateways/Application-Level-Gateway.htm ALG - Application Level Gateway]</ref>, telles que :
* introduction d'un délai pour le traitement des paquets ;
* difficultés à passer le facteur d'échelle, et possibilité de congestion ;
* applications non conçues pour fonctionner avec un relais intermédiaire.
{{HorsTexte|Passage à l'échelle|Le passage à l'échelle, dans ce contexte, signifie une croissance de la taille, soit en nombre de clients du service applicatif, soit en terme de volume de flux. La mise en place d'une passerelle applicative ajoute un relais protocolaire dans la chaîne de communication entre le client et le serveur applicatif. Bien que ce relais puisse être fonctionnel et transparent, la montée en charge peut poser problème. La capacité du relais étant finie et limitée, il peut introduire des défauts à partir d'un certain nombre de clients ou d'une certaine quantité de trafic.}}

En effet, des protocoles propriétaires ainsi que certains protocoles assurant la confidentialité des communications peuvent rendre impossible la mise en œuvre d'un tel dispositif (pour un protocole de sécurité, une telle passerelle pourrait s'apparenter à un "homme au milieu"). De plus, selon le protocole utilisé, la mise en œuvre d'une telle passerelle peut s'avérer complexe. Par exemple, le protocole SIP nécessite une interprétation de l'ensemble de la signalisation. Enfin, une passerelle applicative n'est pas forcément le meilleur choix si le protocole applicatif embarque des adresses IP.

== Références bibliographiques ==
<references />

== Pour aller plus loin ==
RFC et leur analyse par S. Bortzmeyer
* RFC 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]
* RFC 6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation
* RFC 6586 Experiences from an IPv6-Only Network [http://www.bortzmeyer.org/6586.html Analyse]
* RFC 6589 Considerations for Transitioning Content to IPv6 [http://www.bortzmeyer.org/6589.html Analyse]
* RFC 6883 IPv6 Guidance for Internet Content Providers and Application Service Providers [http://www.bortzmeyer.org/6883.html Analyse]
* RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269.html Analyse]

MOOC:Corrections s8

2022-12-14T03:28:36Z

Panelli: /* Seq2 */

Remplacer les QCM à réponses multiples par des systèmes de questions à réponse simple (ex: Ajouter une proposition vraie et ajouter une proposition "toutes les propositions sont vraies")

== Seq0 ==
A02Q04 : "adresse IP" => "adresse IP publique"

Doc compagnon A02 : Donner une définition de datagramme

== Seq1 ==
A11E01 : Revoir le calcul (prise en compte des années bissextiles)
''20221212; JL : remplacement des valeurs calculées sur la base de 365,25 jours/an au lieu de 365 dans la version précédente''

A12E02 : Rappeler (doc compagnon ou dans indice) que l'IID peut être nul.

''20221212; JL : Dans l'indice il est déjà indiqué qu' "il n'y a pas d'adresse réservée dans un sous-réseau".
Ajout au doc compagnon d'un nota au paragraphe "Identification locale : l'IID (Interface IDentifier)" de l'activité A14''

Bien indiquer dans le doc compagnon qu'il n'y a pas d'adresse de broadcast

''20221212; JL : Act13, les passages concernés sont à présent en "gras".
(cf ''définition du multicast'' et ''explication groupe réservé 1, adresse <tt>ff02::1</tt>)''

Doc compagnon : expliquer les conséquences d'un subnet au delà des 64 bits ?
''20221213; JL : Ajout d'un "hors texte" au parargraphe "Préfixes de sous-réseaux (SID Subnet IDentifier)"
du doc compagnon de l'activité A14.
Doc Compagnon A13 :
* Donner des exemples de construction des adresses multicast sollicité, afin de rendre plus facile la question A13E04.
* Attention une redondance dans le doc compagnon sur le multicast sollicité entre le chapitre A13 et son annexe
* L'exemple pour l'adresse multicast Embedded-RP du point de rendez-vous est 2001:660:3307:125::3 alors qu'à la page suivante on indique son préfixe comme étant 2001:660:3007:125/64 et l'adresse multicast dérivée ff7x:340:2001:660:3007:125:aabb:ccdd. Le 3 de 3307 du point de rendez-vous ne devrait-il pas être un 0?
* Aussi, dans cette section, le format pour les identifiants de groupe aabb:ccdd peut laisser croire que les deux symboles hexadécimaux qui composent un octet doivent être les mêmes, alors qu'il s'agit uniquement de marques de positions des quartets. Ça peut perturber les lecteurs qui ne sont pas familiers avec l'hexadécimal et qui pourraient penser que 11aa:77ee est un identifiant de groupe valide alors que 12ab:78ef ne l'est pas.

Vidéo A13 partie 1 : Au niveau du cours A13 partie 1 à la minute 7:00, le fd de l'adresse locale unique est représenté 11110001 en binaire au lieu de 11111101

Doc Compagnon A14 :
* donner un exemple de construction de l'IID à partir de l'adresse MAC
* nouvelle structure pour les adresses multicast IPv6 ? (RFC3306 et 7371)
* Donner un pointeur vers une calculette subnet (exemple : https://fr.rakko.tools/tools/27/)
* Etendre la mise en oeuvre pour Windows. J'ai lu la page 63. Il faudrait la modifier pour utiliser la terminologie Microsoft :
** Adresse IPv6 de type "Public" pour les flux entrants,
** Adresse IPv6 de type "Temporaire" pour les flux sortants.

Toutes deux ont un IID généré pseudo-aléatoirement.
Cette ressource est plus claire il me semble : https://www.networkacademy.io/ccna/ipv6/ipv6-on-windows

== Seq2 ==

Exercice A24 : Remplacer l'extension RH0 par une extension de fragmentation

Refaire A23 : QUIZ DOCUMENT COMPAGNON (car doublon) pour les questions
A23Q6
A23Q7
A23Q8

== Seq3 ==

S3E02 : Reformuler la question ?

TP A36 : l'étape 1 contient déjà des configurations, revoir le sujet ?

== Seq4 ==
Doc compagnon A42 / Tunnel configuré : revoir l'adressage des points d'entrée de tunnel (/64 ou /127 ?)

Questions A44 : Attention à l'acronyme ALG :
* A44Q01 : "Application Level Gateway"
* A44Q06 : "Application Layer Gateway"

MOOC:Corrections s8

2022-12-14T03:27:53Z

Panelli:

MOOC:Corrections s8

2022-12-06T19:14:51Z

Panelli: /* Seq2 */

== Seq0 ==
A02Q04 : "adresse IP" => "adresse IP publique"

Doc compagnon A02 : Donner une définition de datagramme

== Seq1 ==
A11E01 : Revoir le calcul (prise de compte des années bissextiles)

A12E02 : Rappeler (doc compagnon ou dans indice) que l'IID peut être nul. Bien indiquer dans le doc compagnon qu'il n'y a pas d'adresse de broadcast

Doc compagnon : expliquer les conséquences d'un subnet au delà des 64 bits ?

Doc Compagnon A13 :
* Donner des exemples de construction des adresses multicast sollicité, afin de rendre plus facile la question A13E04.
* Attention une redondance dans le doc compagnon sur le multicast sollicité entre le chapitre A13 et son annexe
* L'exemple pour l'adresse multicast Embedded-RP du point de rendez-vous est 2001:660:3307:125::3 alors qu'à la page suivante on indique son préfixe comme étant 2001:660:3007:125/64 et l'adresse multicast dérivée ff7x:340:2001:660:3007:125:aabb:ccdd. Le 3 de 3307 du point de rendez-vous ne devrait-il pas être un 0?
* Aussi, dans cette section, le format pour les identifiants de groupe aabb:ccdd peut laisser croire que les deux symboles hexadécimaux qui composent un octet doivent être les mêmes, alors qu'il s'agit uniquement de marques de positions des quartets. Ça peut perturber les lecteurs qui ne sont pas familiers avec l'hexadécimal et qui pourraient penser que 11aa:77ee est un identifiant de groupe valide alors que 12ab:78ef ne l'est pas.

Vidéo A13 partie 1 : Au niveau du cours A13 partie 1 à la minute 7:00, le fd de l'adresse locale unique est représenté 11110001 en binaire au lieu de 11111101

Doc Compagnon A14 :
* donner un exemple de construction de l'IID à partir de l'adresse MAC
* nouvelle structure pour les adresses multicast IPv6 ? (RFC3306 et 7371)
* Donner un pointeur vers une calculette subnet (exemple : https://fr.rakko.tools/tools/27/)
* Etendre la mise en oeuvre pour Windows. J'ai lu la page 63. Il faudrait la modifier pour utiliser la terminologie Microsoft :
** Adresse IPv6 de type "Public" pour les flux entrants,
** Adresse IPv6 de type "Temporaire" pour les flux sortants.

Toutes deux ont un IID généré pseudo-aléatoirement.
Cette ressource est plus claire il me semble : https://www.networkacademy.io/ccna/ipv6/ipv6-on-windows

== Seq2 ==

Exercice A24 : Remplacer l'extension RH0 par une extension de fragmentation

Refaire A23 : QUIZ DOCUMENT COMPAGNON (car doublon)

== Seq3 ==

S3E02 : Reformuler la question ?

TP A36 : l'étape 1 contient déjà des configurations, revoir le sujet ?

== Seq4 ==
Doc compagnon A42 / Tunnel configuré : revoir l'adressage des points d'entrée de tunnel (/64 ou /127 ?)

Questions A44 : Attention à l'acronyme ALG :
* A44Q01 : "Application Level Gateway"
* A44Q06 : "Application Layer Gateway"

MOOC:Gestion de projet

2022-12-06T11:28:12Z

Panelli: /* Sessions FUN */

> [[MOOC:Accueil|MOOC]]>[[MOOC:Gestion_de_projet|Gestion de projet]]
----
= Sessions FUN=
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012/session01 Session 1 Trimestre 4 2015]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S02/session02/about Session 2 Trimestre 2 2016]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S03/session03/about Session 3 Trimestre 2 2017]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session04/about Session 4 Trimestre 2 2018]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/about Session 5 Trimestre 3 2019] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/about Session 6 Sesmestre 1 2021] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/about Session 7 Sesmestre 1 2022] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session07 Studio] et [https://www.fun-mooc.fr/fr/cours/objectif-ipv6/?edit présentation] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/fun/dashboard/ Tableau de bord du cours]

* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session08/about Session 8 Sesmestre 1 2023] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session08 Studio]

== Bilan ==
[https://docs.google.com/spreadsheets/d/1PUOKsLGiOqckVbqWy1jh4ZoixsOUtKyit13ypD8x0us/edit?usp=sharing Audiences des différentes sessions]

= Documents de travail =

== Session 8 ==
* [[MOOC:Corrections s8|Corrections pour la session 8]]

== Session 7 (refonte) ==

==== Actions ====
* [[MOOC:Plan_decouverte| Plan du cours : découverte]]
* [https://miro.com/app/board/o9J_lYdjJSw=/ Tableau blanc des ateliers] (Miro)
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Taches Session 7| Liste des tâches]]
* [[MOOC:Table des corrections7|Table des corrections]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=263830683 Méta et scénarisation du cours sur FUN]

==== Comptes rendus ====

* [[MOOC:Réunion_20220121|20220121 Réunion coordination Session 7]]
* [[MOOC:Réunion_20210707|20210707 Réunion Avancement]]
* [[MOOC:Réunion_20210618|20210618 Réunion Bilan Session 6]]
* [[MOOC:Réunion_20210531|20210531 Atelier 6 : Refonte Compagnon et Seq1]]
* [[MOOC:Réunion_20210520|20210520 Atelier 5 : Renommage activités et Seq3]]
* [[MOOC:Réunion_20210503|20210503 Atelier 4 : Plan découverte et Seq4]]
* [[MOOC:Réunion_20210426|20210426 Atelier 3 : Evolution Découverte]]
* [[MOOC:Réunion_20210401|20210401 Atelier 2 : Plan découverte]]
* [[MOOC:Réunion_20210315|20210315 Atelier 1 : Structuration]]

== Guides et Aides ==
* [[MOOC:Guide de rédaction|Guide de rédaction]]
* [[MOOC:Guide de tournage|Guide de tournage]]
* [[MOOC:Guide des quizz|Guide des quizz]]
* [[MOOC:Ouverture de séquence|Guide de l'ouverture de session]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=480308602 Méta et scénarisation du cours sur FUN]

=== Informations ===
* Objectifs pédagogiques: [http://fr.wikipedia.org/wiki/Taxonomie_de_Bloom taxonomie de Bloom] (limiter aux niveaux 1, 2 voir 3)
* [[MOOC:Stats Compagnon| Statistiques sur le document compagnon]]

= Outils =
* [http://wiki.g6.asso.fr/index.php?title=Annuaire_Intervenants_MOOC Annuaire Intervenants MOOC]
* [https://docs.google.com/spreadsheets/d/1xwPM_2cbo_Fw9iTS14YyU2VpbufOT0v8NVUMRgp1I9Q/edit?usp=sharing Annuaire] (nouveau)
* Liste de diffusion [mailto:mooc-ipv6@imt-atlantique.fr mooc ipv6]
** La page d'accueil de la liste : https://listes.imt-atlantique.fr/wws/info/mooc-ipv6
** Introduction aux listes de diffusion : https://listes.imt-atlantique.fr/wws/help/introduction
* [[MOOC:Lille| Séjour à IMT Lille]]
* [http://livre.g6.asso.fr/index.php?title=Special:Search&fulltext=Search&profile=advanced Recherche sur le Wiki]
* [https://docs.google.com/document/d/1A72NHGB17awkHqUOrm-KFAjbiMb3dUdV3v-z0tRB7lA/edit Le Tableau blanc]
* [https://us04web.zoom.us/j/9708780848 Session ZOOM ]

= Archive comptes rendus de réunions =
* [[MOOC:Réunion_20201118|20201118 Point d'avancement]]
* [[MOOC:Réunion_20200615|20200615 Réunion pédago]]
* [[MOOC:Réunion_20200527|20200527 Point d'avancement]]
* [[MOOC:Réunion_20200402|20200402 Réunion pédago]]
* [[MOOC:Réunion_20200306|20200306 Réunion fin de rédaction]]
* [[MOOC:Réunion_20200212|20200212 Réunion refonte session6 2]]
* [[MOOC:Réunion_20200121|20200121 Réunion refonte session6]]
* [[MOOC:Réunion_20190927|20190927 Réunion bilan session5]]
* [[MOOC:Réunion_20190319|20190319 Réunion session5]]
* [[MOOC:Réunion_20181019|20181019 Réunion refonte]]
* [[MOOC:Réunion_20180709|20180709 Réunion bilan session 4]]
* [[MOOC:Réunion_20170306|20170306 Réunion d'avancement session3]]
* [https://docs.google.com/document/d/1hjqUmFv2WvJfgRcuBQS0mXItJRGAYqpearu2qFvCxG4/edit#heading=h.5ajsmpmo8nls 20161128 Réunion de reprise de contact]
* [https://docs.google.com/document/d/1dQn_fgq3Z8UTpW1pZ647lCisXwpU_6c-_Q0jFqNEjT8/edit#heading=h.7e8c433picx9 20160616 Réunion bilan session2]
* [[MOOC:Réunion_20160414|20160414 Réunion d'avancement2]]
* [[MOOC:Réunion_20160401|20160401 Réunion d'avancement1]]
* [[MOOC:Réunion 20160209|20160209 Réunion avant session 2]]
* [[MOOC:Réunion 20151207|20151207 Réunion bilan session1]]
* [[MOOC:Réunion 20151006|20151006 Réunion finalisation]]
* [[MOOC:Réunion 20150904|20150904 Réunion d'avancement]]
* [[MOOC:Réunion 20150311|20150311 Réunion de synchronisation]]
* [[MOOC:Réunion 20150306|20150306 Réunion d'avancement]]
* [[MOOC:Réunion 20150216|20150216 Réunion d'avancement]]
* [[MOOC:Réunion 20150203|20150203 Réunion d'avancement]]
* [[MOOC:Réunion 20150115|20150115 Réunion d'avancement]]
* [[MOOC:Réunion 20141211|20141211 Rencontre MOOC Paris]]
* [[MOOC:Réunion 20141201|20141201 Réunion d'avancement]]
* [[MOOC:Réunion 20141124|20141124 Réunion Articulation PRD/IPv6]]
* [[MOOC:Réunion 20141031|20141031 Réunion de démarrage]]

= Archives =

== Session 6 ==

==== Actions ====

* [[MOOC:Evolutions | Syllabus session 6]]
* [[MOOC:Taches Session 6| Liste des tâches]]
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Table des corrections6|Table des corrections]]

* [[MOOC:Bilan Session 6|Bilan Session 6]]

===== Animation =====

* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/ Cours en ligne]
** [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session06 Studio]
* [[MOOC:Cahier des corrections|Cahier des corrections]]

== Session 5 ==
* [[MOOC:Session_5-Taches| Liste des tâches]]
* [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session05 Studio]
* [[MOOC:Bilan_Session5|Bilan Session 5]]
* [[MOOC:Manuel_Apprenant_Session5|archive manuel apprenant session5]]

== Session 4 ==
* [[MOOC:Bilan_Session_4]]

== Session 3 ==
* [[MOOC:Taches_Session_3]]
* [[MOOC:Matrice relecture Compagnon]]
* [[MOOC:Matrice des Quiz]]
* [[MOOC:Session3-Alignement Evaluations| Alignement Evaluations]]
* [[MOOC:Bilan_Session_3]]
* [[MOOC:Erratum_Session_3]]

=== Session 2===
* [[MOOC:Taches Session 2]]
* [[MOOC:Corrections des videos]]

=== Session 1===
* [[MOOC:Formalisation de la structure]]
* [[MOOC:Figures]]
* [[MOOC:Matrice des séquences]]
* [[MOOC:Matrice des auteurs]]
* [[MOOC:Bilan Session1]]
* [[MOOC:Cahier_des_Charges_Plateforme_Lab|Cahier des charges de la plateforme Lab]]

=Communication=
* Page d'annonce du MOOC IPv6 sur FUN : [https://www.france-universite-numerique-mooc.fr/courses/MinesTelecom/04012/session01/about Objectif IPv6 : vers l'internet nouvelle génération]
* Annonces faites par l'Université de la Réunion:
** [[MOOC:comUR | Message du 15 juillet]]
** Sur le site institutionnel : [http://www.univ-reunion.fr/actualites/ipv6-le-premier-mooc-de-luniversite-de-la-reunion/ Actualités]

* Presentation du plan: https://prezi.com/jjmq_45fjhfr/mooc-objectif-ipv6-plan-du-cours/

* Pour les avis mymooc https://www.my-mooc.com/fr/mooc/objectif-ipv6-vers-linternet-nouvelle-generation/

MOOC:Gestion de projet

2022-12-06T11:27:54Z

Panelli: /* Sessions FUN */

> [[MOOC:Accueil|MOOC]]>[[MOOC:Gestion_de_projet|Gestion de projet]]
----
= Sessions FUN=
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012/session01 Session 1 Trimestre 4 2015]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S02/session02/about Session 2 Trimestre 2 2016]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S03/session03/about Session 3 Trimestre 2 2017]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session04/about Session 4 Trimestre 2 2018]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/about Session 5 Trimestre 3 2019] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/about Session 6 Sesmestre 1 2021] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/about Session 7 Sesmestre 1 2022] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session07 Studio] et [https://www.fun-mooc.fr/fr/cours/objectif-ipv6/?edit présentation] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/fun/dashboard/ Tableau de bord du cours]

* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session08/about Session 8 Sesmestre 1 2023] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session08]

== Bilan ==
[https://docs.google.com/spreadsheets/d/1PUOKsLGiOqckVbqWy1jh4ZoixsOUtKyit13ypD8x0us/edit?usp=sharing Audiences des différentes sessions]

= Documents de travail =

== Session 8 ==
* [[MOOC:Corrections s8|Corrections pour la session 8]]

== Session 7 (refonte) ==

==== Actions ====
* [[MOOC:Plan_decouverte| Plan du cours : découverte]]
* [https://miro.com/app/board/o9J_lYdjJSw=/ Tableau blanc des ateliers] (Miro)
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Taches Session 7| Liste des tâches]]
* [[MOOC:Table des corrections7|Table des corrections]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=263830683 Méta et scénarisation du cours sur FUN]

==== Comptes rendus ====

* [[MOOC:Réunion_20220121|20220121 Réunion coordination Session 7]]
* [[MOOC:Réunion_20210707|20210707 Réunion Avancement]]
* [[MOOC:Réunion_20210618|20210618 Réunion Bilan Session 6]]
* [[MOOC:Réunion_20210531|20210531 Atelier 6 : Refonte Compagnon et Seq1]]
* [[MOOC:Réunion_20210520|20210520 Atelier 5 : Renommage activités et Seq3]]
* [[MOOC:Réunion_20210503|20210503 Atelier 4 : Plan découverte et Seq4]]
* [[MOOC:Réunion_20210426|20210426 Atelier 3 : Evolution Découverte]]
* [[MOOC:Réunion_20210401|20210401 Atelier 2 : Plan découverte]]
* [[MOOC:Réunion_20210315|20210315 Atelier 1 : Structuration]]

== Guides et Aides ==
* [[MOOC:Guide de rédaction|Guide de rédaction]]
* [[MOOC:Guide de tournage|Guide de tournage]]
* [[MOOC:Guide des quizz|Guide des quizz]]
* [[MOOC:Ouverture de séquence|Guide de l'ouverture de session]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=480308602 Méta et scénarisation du cours sur FUN]

=== Informations ===
* Objectifs pédagogiques: [http://fr.wikipedia.org/wiki/Taxonomie_de_Bloom taxonomie de Bloom] (limiter aux niveaux 1, 2 voir 3)
* [[MOOC:Stats Compagnon| Statistiques sur le document compagnon]]

= Outils =
* [http://wiki.g6.asso.fr/index.php?title=Annuaire_Intervenants_MOOC Annuaire Intervenants MOOC]
* [https://docs.google.com/spreadsheets/d/1xwPM_2cbo_Fw9iTS14YyU2VpbufOT0v8NVUMRgp1I9Q/edit?usp=sharing Annuaire] (nouveau)
* Liste de diffusion [mailto:mooc-ipv6@imt-atlantique.fr mooc ipv6]
** La page d'accueil de la liste : https://listes.imt-atlantique.fr/wws/info/mooc-ipv6
** Introduction aux listes de diffusion : https://listes.imt-atlantique.fr/wws/help/introduction
* [[MOOC:Lille| Séjour à IMT Lille]]
* [http://livre.g6.asso.fr/index.php?title=Special:Search&fulltext=Search&profile=advanced Recherche sur le Wiki]
* [https://docs.google.com/document/d/1A72NHGB17awkHqUOrm-KFAjbiMb3dUdV3v-z0tRB7lA/edit Le Tableau blanc]
* [https://us04web.zoom.us/j/9708780848 Session ZOOM ]

= Archive comptes rendus de réunions =
* [[MOOC:Réunion_20201118|20201118 Point d'avancement]]
* [[MOOC:Réunion_20200615|20200615 Réunion pédago]]
* [[MOOC:Réunion_20200527|20200527 Point d'avancement]]
* [[MOOC:Réunion_20200402|20200402 Réunion pédago]]
* [[MOOC:Réunion_20200306|20200306 Réunion fin de rédaction]]
* [[MOOC:Réunion_20200212|20200212 Réunion refonte session6 2]]
* [[MOOC:Réunion_20200121|20200121 Réunion refonte session6]]
* [[MOOC:Réunion_20190927|20190927 Réunion bilan session5]]
* [[MOOC:Réunion_20190319|20190319 Réunion session5]]
* [[MOOC:Réunion_20181019|20181019 Réunion refonte]]
* [[MOOC:Réunion_20180709|20180709 Réunion bilan session 4]]
* [[MOOC:Réunion_20170306|20170306 Réunion d'avancement session3]]
* [https://docs.google.com/document/d/1hjqUmFv2WvJfgRcuBQS0mXItJRGAYqpearu2qFvCxG4/edit#heading=h.5ajsmpmo8nls 20161128 Réunion de reprise de contact]
* [https://docs.google.com/document/d/1dQn_fgq3Z8UTpW1pZ647lCisXwpU_6c-_Q0jFqNEjT8/edit#heading=h.7e8c433picx9 20160616 Réunion bilan session2]
* [[MOOC:Réunion_20160414|20160414 Réunion d'avancement2]]
* [[MOOC:Réunion_20160401|20160401 Réunion d'avancement1]]
* [[MOOC:Réunion 20160209|20160209 Réunion avant session 2]]
* [[MOOC:Réunion 20151207|20151207 Réunion bilan session1]]
* [[MOOC:Réunion 20151006|20151006 Réunion finalisation]]
* [[MOOC:Réunion 20150904|20150904 Réunion d'avancement]]
* [[MOOC:Réunion 20150311|20150311 Réunion de synchronisation]]
* [[MOOC:Réunion 20150306|20150306 Réunion d'avancement]]
* [[MOOC:Réunion 20150216|20150216 Réunion d'avancement]]
* [[MOOC:Réunion 20150203|20150203 Réunion d'avancement]]
* [[MOOC:Réunion 20150115|20150115 Réunion d'avancement]]
* [[MOOC:Réunion 20141211|20141211 Rencontre MOOC Paris]]
* [[MOOC:Réunion 20141201|20141201 Réunion d'avancement]]
* [[MOOC:Réunion 20141124|20141124 Réunion Articulation PRD/IPv6]]
* [[MOOC:Réunion 20141031|20141031 Réunion de démarrage]]

= Archives =

== Session 6 ==

==== Actions ====

* [[MOOC:Evolutions | Syllabus session 6]]
* [[MOOC:Taches Session 6| Liste des tâches]]
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Table des corrections6|Table des corrections]]

* [[MOOC:Bilan Session 6|Bilan Session 6]]

===== Animation =====

* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/ Cours en ligne]
** [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session06 Studio]
* [[MOOC:Cahier des corrections|Cahier des corrections]]

== Session 5 ==
* [[MOOC:Session_5-Taches| Liste des tâches]]
* [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session05 Studio]
* [[MOOC:Bilan_Session5|Bilan Session 5]]
* [[MOOC:Manuel_Apprenant_Session5|archive manuel apprenant session5]]

== Session 4 ==
* [[MOOC:Bilan_Session_4]]

== Session 3 ==
* [[MOOC:Taches_Session_3]]
* [[MOOC:Matrice relecture Compagnon]]
* [[MOOC:Matrice des Quiz]]
* [[MOOC:Session3-Alignement Evaluations| Alignement Evaluations]]
* [[MOOC:Bilan_Session_3]]
* [[MOOC:Erratum_Session_3]]

=== Session 2===
* [[MOOC:Taches Session 2]]
* [[MOOC:Corrections des videos]]

=== Session 1===
* [[MOOC:Formalisation de la structure]]
* [[MOOC:Figures]]
* [[MOOC:Matrice des séquences]]
* [[MOOC:Matrice des auteurs]]
* [[MOOC:Bilan Session1]]
* [[MOOC:Cahier_des_Charges_Plateforme_Lab|Cahier des charges de la plateforme Lab]]

=Communication=
* Page d'annonce du MOOC IPv6 sur FUN : [https://www.france-universite-numerique-mooc.fr/courses/MinesTelecom/04012/session01/about Objectif IPv6 : vers l'internet nouvelle génération]
* Annonces faites par l'Université de la Réunion:
** [[MOOC:comUR | Message du 15 juillet]]
** Sur le site institutionnel : [http://www.univ-reunion.fr/actualites/ipv6-le-premier-mooc-de-luniversite-de-la-reunion/ Actualités]

* Presentation du plan: https://prezi.com/jjmq_45fjhfr/mooc-objectif-ipv6-plan-du-cours/

* Pour les avis mymooc https://www.my-mooc.com/fr/mooc/objectif-ipv6-vers-linternet-nouvelle-generation/

MOOC:Ressources

2022-05-04T05:49:25Z

Panelli: /* Internet Usage */

> [[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]]>[[MOOC:Ressources|Ressources]]
----
= Ressources bibliographiques=

===Articles===
*Bernstein, Daniel J. [http://cr.yp.to/djbdns/ipv6mess.html The IPv6 mess].
*. Cui Y., Wu P., Xu M., et al., “4over6: Network Layer Virtualization for IPv4-IPv6 Coexistence,” IEEE Network, October 2012.

=== Livres===

* Graziani, R. (2012). Ed.: Cisco Press. [http://proquest.safaribooksonline.com/book/networking/ip/9780133033496 BookOnLine] IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6
* liste sur la page de Pascal [[User:Panelli|Anelli]]
* Migrating to IPv6: A Practical Guide to Implementing IPv6 in Mobile and FIxed network Par Marc Blanchet

====IETF WG====
* [https://datatracker.ietf.org/wg/v6ops/charter/ V6ops]
* [https://datatracker.ietf.org/wg/6man/charter/ IPv6 maintenance]
* [https://datatracker.ietf.org/wg/softwire/charter/ Softwire]

===RFC===
Référence <strike>barrée</strike> si reprise dans une séquence

* RFC 8956 Dissemination of Flow Specification Rules for IPv6
* RFC 8883 ICMPv6 Errors for Discarding Packets Due to Processing Limits
* RFC 8781 Discovering PREF64 in Router Advertisements
* RFC 8754 on IPv6 Segment Routing Header (SRH)
* RFC 8504: IPv6 Node Requirements([http://www.bortzmeyer.org/8504.html Bortzmeyer])
* RFC 8501: Reverse DNS in IPv6 for Internet Service Providers ([http://www.bortzmeyer.org/8501.html Bortzmeyer])
* RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) ([http://www.bortzmeyer.org/8415.html Bortzmeyer])
* RFC 8201 Path MTU Discovery for IP version 6 ([http://www.bortzmeyer.org/8201.html Bortzmeyer])
* RFC 8200 Internet Protocol, Version 6 (IPv6) Specification ([http://www.bortzmeyer.org/8200.html Bortzmeyer])
* RFC 8021: Generation of IPv6 Atomic Fragments Considered Harmful ([http://www.bortzmeyer.org/8021.html Bortzmeyer])
* RFC 7608 IPv6 Prefix Length Recommendation for Forwarding
* RFC 7600 IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)
* RFC 7599 Mapping of Address and Port using Translation (MAP-T)
* RFC 7596 Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture
* RFC 7421 Analysis of the 64-bit Boundary in IPv6 Addressing ([http://www.bortzmeyer.org/7421.html Bortzmeyer])
* RFC 7411 Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers
* RFC 7404 Using Only Link-Local Addressing inside an IPv6 Network ([http://www.bortzmeyer.org/7404.html Bortzmeyer])
* RFC 7381 Enterprise IPv6 Deployment Guidelines ([http://www.bortzmeyer.org/7381 Bortzmeyer])
* RFC 7368 IPv6 Home Networking Architecture Principles
* RFC 7346 IPv6 Multicast Address Scopes
* RFC 7269 NAT64 Deployment Options and Experience ([http://www.bortzmeyer.org/7269 Bortzmeyer])
* RFC 7227 Guidelines for Creating New DHCPv6 Options
* RFC 7225 Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP) ([http://www.bortzmeyer.org/7225 Bortzmeyer])
* RFC 7219 SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI)
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) ([http://www.bortzmeyer.org/7217.html Bortzmeyer])
* RFC 7148 Prefix Delegation Support for Proxy Mobile IPv6
* RFC 7136 Significance of IPv6 Interface Identifiers ([http://www.bortzmeyer.org/7136.html Bortzmeyer])
* RFC 7123 Security Implications of IPv6 on IPv4 Networks ([http://www.bortzmeyer.org/7123 Bortzmeyer])
* RFC 7112 Implications of Oversized IPv6 Header Chains
* RFC 7098 Using the IPv6 Flow Label for Load Balancing in Server Farms
* RFC 7084 Basic Requirements for IPv6 Customer Edge Routers
* RFC 7059 A Comparison of IPv6-over-IPv4 Tunnel Mechanisms ([http://www.bortzmeyer.org/7059 Bortzmeyer])
* RFC 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix
* RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis ([http://www.bortzmeyer.org/7050 Bortzmeyer])
* RFC 7048 Neighbor Unreachability Detection Is Too Impatient
* RFC 7045 Transmission and Processing of IPv6 Extension Headers
* RFC 7040 Public IPv4-over-IPv6 Access Network
* RFC 7010 IPv6 Site Renumbering Gap Analysis ([http://www.bortzmeyer.org/7010.html Bortzmeyer])
* RFC 6980 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
* RFC 6948 Some Measurements on World IPv6 Day from an End-User Perspective ([http://www.bortzmeyer.org/6948.html Bortzmeyer])
* RFC 6946 Processing of IPv6 "Atomic" Fragments
* RFC 6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums
* RFC 6935 IPv6 and UDP Checksums for Tunneled Packets ([http://www.bortzmeyer.org/6935 Bortzmeyer])
* RFC 6908 Deployment Considerations for Dual-Stack Lite ([http://www.bortzmeyer.org/6908 Bortzmeyer])
* RFC 6890 Special-Purpose IP Address Registries ([http://www.bortzmeyer.org/6890.html Bortzmeyer])
* RFC 6889 Analysis of Stateful 64 Translation
* RFC 6879 IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods ([http://www.bortzmeyer.org/6879.html Bortzmeyer])
* RFC 6877 464XLAT: Combination of Stateful and Stateless Translation
* RFC 6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers ([http://www.bortzmeyer.org/6874.html Bortzmeyer])
* RFC 6866 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks ([http://www.bortzmeyer.org/6866.html Bortzmeyer])
* RFC 6791 Stateless Source Address Mapping for ICMPv6 Packets
* RFC 6782 Wireline Incremental IPv6 ([http://www.bortzmeyer.org/6782 Bortzmeyer])
* RFC 6752 Issues with Private IP Addressing in the Internet
* RFC 6732 6to4 Provider Managed Tunnels
* RFC 6724 Default Address Selection for Internet Protocol Version 6 (IPv6) ([http://www.bortzmeyer.org/6724.html Bortzmeyer])
* RFC 6611 Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario
* RFC 6586 Experiences from an IPv6-Only Network ([http://www.bortzmeyer.org/6586 Bortzmeyer])
* RFC 6654 Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd)
* RFC 6589 Considerations for Transitioning Content to IPv6 ([http://www.bortzmeyer.org/6589 Bortzmeyer])
* RFC 6586 Experiences from an IPv6-Only Network
* RFC 6583 Operational Neighbor Discovery Problems
* RFC 6564 A Uniform Format for IPv6 Extension Headers
* RFC 6555 Happy Eyeballs: Success with Dual-Stack Hosts ([http://www.bortzmeyer.org/6555.html Bortzmeyer])
* RFC 6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6
* RFC 6540 IPv6 Support Required for All IP-Capable Nodes
* RFC 6496 Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)
* RFC 6437 IPv6 Flow Label Specification, voir aussi RFC 6438, RFC 6436
* RFC 6434 IPv6 Node Requirements
* RFC 6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation
* <strike>RFC 6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage ([http://www.bortzmeyer.org/6346.html Bortzmeyer])</strike>
* RFC 6343 Advisory Guidelines for 6to4 Deployment
* RFC 6342 Mobile Networks Considerations for IPv6 Deployment, aussi RFC 6212
* RFC 6334 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite ([http://www.bortzmeyer.org/6334 Bortzmeyer])
* RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion ([http://www.bortzmeyer.org/6333 Bortzmeyer])
* RFC 6324 Routing Loop Attack Using IPv6 Automatic Tunnels
* RFC 6301 A Survey of Mobility Support in the Internet
* RFC 6294 Survey of Proposed Use Cases for the IPv6 Flow Label
* RFC 6275 Mobility Support in IPv6
* RFC 6221 Lightweight DHCPv6 Relay Agent
* RFC 6204 Basic Requirements for IPv6 Customer Edge Routers
* RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment ([http://www.bortzmeyer.org/6180 Bortzmeyer])
* RFC 6177 IPv6 Address Assignment to End Sites ([http://www.bortzmeyer.org/6177.html Bortzmeyer])
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links ([http://www.bortzmeyer.org/6164.html Bortzmeyer])
* RFC 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers ([http://www.bortzmeyer.org/6147 Bortzmeyer])
* RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers ([http://www.bortzmeyer.org/6146 Bortzmeyer])
* RFC 6145 IP/ICMP Translation Algorithm ([http://www.bortzmeyer.org/6145 Bortzmeyer])
* RFC 6144 Framework for IPv4/IPv6 Translation ([http://www.bortzmeyer.org/6144 Bortzmeyer])
* RFC 6127 IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios
* RFC 6106 IPv6 Router Advertisement Options for DNS Configuration
* RFC 6104: Rogue IPv6 Router Advertisement Problem Statement
* RFC 6092: Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [http://www.bortzmeyer.org/6092 Bortzmeyer])
* RFC 6085 Address Mapping of IPv6 Multicast Packets on Ethernet
* RFC 6081 Teredo Extensions
* RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators ([http://www.bortzmeyer.org/6052 Bortzmeyer])
* RFC 6036 Emerging Service Provider Scenarios for IPv6 Deployment ([http://www.bortzmeyer.org/6036 Bortzmeyer])
* RFC 5952 A Recommendation for IPv6 Address Text Representation ([http://www.bortzmeyer.org/5952.html Bortzmeyer])
* RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
* RFC 5902 IAB Thoughts on IPv6 Network Address Translation ([http://www.bortzmeyer.org/5902 Bortzmeyer])
* RFC 5722 Handling of Overlapping IPv6 Fragments
* RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) ([http://www.bortzmeyer.org/5569 Bortzmeyer])
* RFC 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) ([http://www.bortzmeyer.org/5572 Bortzmeyer])
* RFC 5453 Reserved IPv6 Interface Identifiers ([http://www.bortzmeyer.org/5453.html Bortzmeyer])
* RFC 5375 IPv6 Unicast Address Assignment Considerations ([http://www.bortzmeyer.org/5375.html Bortzmeyer])
* RFC 5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
* RFC 5156 Special-Use IPv6 Addresses ([http://www.bortzmeyer.org/5156.html Bortzmeyer])
* RFC 4966 Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status
* RFC 4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks
* RFC 4925 Softwire Problem Statement ([http://www.bortzmeyer.org/4925 Bortzmeyer])
* RFC 4864 Local Network Protection for IPv6 ([http://www.bortzmeyer.org/4864 Bortzmeyer])
* RFC 4862 IPv6 Stateless Address Autoconfiguration
* RFC 4821 Packetization Layer Path MTU Discovery ([[http://www.bortzmeyer.org/4821.html Bortzmeyer]])
* RFC 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
* RFC 4213 Transition Mechanisms for IPv6 Hosts and Routers ([http://www.bortzmeyer.org/4213 Bortzmeyer])

===Support du G6===
* Cours IPv6 déploiement de P. Anelli ([http://lim.univ-reunion.fr/staff/panelli/4_teaching/IUT/RT2-TR3/P-IPv6-transition.pdf pdf])
* Chapitre du livre Intégration du G6 [http://livre.g6.asso.fr/index.php?title=Intégration_d%27IPv6_et_des_applications ici]
* Slides du G6 sur l'Intégration ([http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/G6_slides-integration.pdf pdf])
* La base des slides du G6 ( [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/AllG6Slides.pdf pdf] )
* Formation G6 par L Toutain [http://c2.touta.in/?page_id=323]
* [[Table des matières|Livre "IPv6, Théorie et Pratique"]]
* [http://g6.asso.fr/formation Support de cours G6]

=== Références générales ===
* [http://www.6deploy.eu/index.php?page=tutorials2 Tutorials 6Deploy-2]
* Support TutTelNet IPv6 (Telecom Lille)
* Cours IPv6 de P. Anelli (IUT R&T) [http://lim.univ-reunion.fr/staff/panelli/4_teaching/IUT/index.html lien]
* [http://www.ripe.net/lir-services/training/courses Cours de RIPE ]
* [http://www.internetsociety.org/deploy360/roadmap/ipv6/ Dossier IPv6 par l'Internet Society]: cours stats, video, how-to, etc.
* [http://www.ipv6actnow.org/info/transition/ Mécanismes de Transition] par IPv6 Act Now
* [http://www.ripe.net/lir-services/training/e-learning/ipv6/useful-links Les mécanismes de Transition] par RIPE (des liens, des vidéos)
* [http://www.isatap.org/ isatap.org] Les ressources pour ISATAP
* [https://www.nanog.org/archives/presentations?k=IPv6&s=0&m=0&a=search NANOG] Présentations NANOG sur IPv6
* [http://www.potaroo.net/ispcol/index.html The ISP Column]
* Nanog: [http://www.nanog.org/meetings/nanog49/presentations/IPv6atGoogle.pdf IPv6atGoogle]
* Moving to IPv6 (Nanog) [https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf pdf]
* IPv6 to Standard [http://www.ipv6-to-standard.org/ url]
* The IPv6 Portal [http://www.ipv6tf.org url]
* Lothaire Yarding "Yet Another Ipv6 to the Next Generation", Université de Lorraine, Lothaire, par Julien Vaubourg [http://julien.vaubourg.com/files/lothaire-yarding_ipv6.pdf Lothaire Yarding]
* LinkedIn Learning : [https://www.linkedin.com/learning/decouvrir-ipv6/ Découvrir IPv6 (Cours conçu par : Rudi Bruchez)]
* A titre de demonstration, il y a ce site: http://www.fredbovy.com/modulation/Modules.html qui présente quelques animations

===Adressage===

* http://www.cbtnuggets.com/it-training-videos/course/cbtn_ipv6 (Vidéos comprehensives mais non-gratuites de Keith )
* https://www.youtube.com/channel/UCrCh8p6p2UZC18vqSBhN_sA (chaîne Youtube de Keith)
* [https://www.youtube.com/watch?v=rljkNMySmuM&index=1&list=PL7FBD333BAB233A44 Keith Barker "Make Sense of an IPv6 Address"]
* [https://www.youtube.com/watch?v=lNev5bboMnM&index=2&list=PL7FBD333BAB233A44 Keith Barker "Lov'n the Link Local Address"]
* [https://tools.ietf.org/html/draft-ietf-6man-why64-08 IETF Draft - Analysis of the 64-bit Boundary in IPv6 Addressing]
* [https://community.infoblox.com/blogs/2015/01/09/do-you-really-need-subnet-calculator-ipv6 Do you really need an IPv6 subnet calculator ?]
* [http://www.ripe.net/lir-services/training/material/basic-ipv6-training-course/Basic-IPv6-Addressing-Plan-With-Possible-Solutions.pdf Exercice du RIPE sur la définition d'un plan d'adressage]
* CISCO. (2008). [http://www.cisco.com/web/strategy/docs/gov/IPv6_WP.pdf IPv6 Addressing White Paper].
* [http://bcop.nanog.org/images/6/62/BCOP-IPv6_Subnetting.pdf NANOG BCOP IPv6 Subnetting]
* http://www.cabrillo.edu/~rgraziani/ipv6.html (Un des meilleurs sites dédié à IPv6)

===vidéo===
* [https://www.youtube.com/watch?v=Od8DDowENMI IPv6 pour les nuls] une présentation faite par des personnels de Microsoft dans un techday.
* [https://www.youtube.com/watch?v=AfFG5jA2S_w Spirent video] sur la transition et globalement les vidéos you tube liées
* [https://www.youtube.com/results?search_query=alantalkstech Vidéos alantalkstech sur Youtube] de spirent
* [https://www.youtube.com/results?search_query=IPv6+Ipv4&search_sort=video_view_count Les vidéos IPv6 sur Youtube]
* [https://www.ripe.net/support/training/videos/ipv6/transition-mechanisms IPv6 Transition Mechanisms] by RIPE

=== Presse. - rapport ===

* [https://thenewstack.io/kubernetes-warms-up-to-ipv6/ Kubernetes Warms Up to IPv6]
*[https://www.numerama.com/tech/529644-ipv6-en-france-le-regulateur-des-telecoms-appelle-a-sy-mettre-de-toute-urgence.html IPv6 en France : le régulateur des télécoms appelle à s’y mettre de « toute urgence »] Numerama juin 2019
* [https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/lipv6/suivi-epuisement-adresses-ipv4.html Suivi de l'épuisement des adresses IPv4] par l'ARCEP
* [https://www.zdnet.fr/actualites/ipv4-la-penurie-d-adresses-disponibles-c-est-pour-novembre-2019-39891627.htm Une "Task force" créée par l'Arcep] zdnet octobre 2019
*[https://www.zdnet.fr/pratique/quelles-recommandations-pour-migrer-vers-ipv6-39860280.htm Quelques recommandations pour migrer vers l'IPv6] zdnet octobre 2019
* [https://www.universfreebox.com/article/51128/IPV4-la-penurie-s-accelere-moins-de-3-millions-d-adresses-disponibles IPV4 : la pénurie s’accélère, moins de 3 millions d’adresses disponibles] Univers FreeBox Juillet 2019
* [https://www.lemagit.fr/actualites/252468059/Penurie-IPv4-comment-lInternet-europeen-sombre-dans-les-magouilles Pénurie IPv4 : comment l’Internet européen sombre dans les magouilles] LeMagIT Aout 2019<br>Une critique d'IPv6
* Zergy (2015) Article en ligne [http://blog.zergy.net/index.php?article2/ipocalypse Ipocalypse]
* Col, P. (2016). ZDNet. [http://www.zdnet.fr/actualites/ipv6-avertissement-solennel-du-ripe-39837614.htm IPv6 : avertissement solennel du RIPE].

=== Internet Usage ===

* Cisco 2018-2023 [https://www.cisco.com/c/en/us/solutions/collateral/executive-perspectives/annual-internet-report/white-paper-c11-741490.html Cisco Annual Internet Report]

* Baromètre annuel de la transition vers IPv6 en France (ARCEP - 2021) [https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transition-ipv6/barometre-annuel-de-la-transition-vers-ipv6-en-france.html Lien]

=== TP ===
* JOOL [http://jool.mx/en/index.html] un code alternatif à Tayga (NAT64)

MOOC:Gestion de projet

2022-03-25T03:59:40Z

Panelli: /* Sessions FUN */

> [[MOOC:Accueil|MOOC]]>[[MOOC:Gestion_de_projet|Gestion de projet]]
----
= Sessions FUN=
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012/session01 Session 1 Trimestre 4 2015]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S02/session02/about Session 2 Trimestre 2 2016]
* [https://www.fun-mooc.fr/courses/MinesTelecom/04012S03/session03/about Session 3 Trimestre 2 2017]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session04/about Session 4 Trimestre 2 2018]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/about Session 5 Trimestre 3 2019] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/about Session 6 Sesmestre 1 2021] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/fun/dashboard/ Tableau de bord du cours]
* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/about Session 7 Sesmestre 1 2022] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session07 Studio] et [https://www.fun-mooc.fr/fr/cours/objectif-ipv6/?edit présentation] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/fun/dashboard/ Tableau de bord du cours]

== Bilan ==
[https://docs.google.com/spreadsheets/d/1PUOKsLGiOqckVbqWy1jh4ZoixsOUtKyit13ypD8x0us/edit?usp=sharing Audiences des différentes sessions]

= Documents de travail =

== Session 7 (refonte) ==

==== Actions ====
* [[MOOC:Plan_decouverte| Plan du cours : découverte]]
* [https://miro.com/app/board/o9J_lYdjJSw=/ Tableau blanc des ateliers] (Miro)
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Taches Session 7| Liste des tâches]]
* [[MOOC:Table des corrections7|Table des corrections]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=263830683 Méta et scénarisation du cours sur FUN]

==== Comptes rendus ====

* [[MOOC:Réunion_20220121|20220121 Réunion coordination Session 7]]
* [[MOOC:Réunion_20210707|20210707 Réunion Avancement]]
* [[MOOC:Réunion_20210618|20210618 Réunion Bilan Session 6]]
* [[MOOC:Réunion_20210531|20210531 Atelier 6 : Refonte Compagnon et Seq1]]
* [[MOOC:Réunion_20210520|20210520 Atelier 5 : Renommage activités et Seq3]]
* [[MOOC:Réunion_20210503|20210503 Atelier 4 : Plan découverte et Seq4]]
* [[MOOC:Réunion_20210426|20210426 Atelier 3 : Evolution Découverte]]
* [[MOOC:Réunion_20210401|20210401 Atelier 2 : Plan découverte]]
* [[MOOC:Réunion_20210315|20210315 Atelier 1 : Structuration]]

== Guides et Aides ==
* [[MOOC:Guide de rédaction|Guide de rédaction]]
* [[MOOC:Guide de tournage|Guide de tournage]]
* [[MOOC:Guide des quizz|Guide des quizz]]
* [[MOOC:Ouverture de séquence|Guide de l'ouverture de session]]

* [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=480308602 Méta et scénarisation du cours sur FUN]

=== Informations ===
* Objectifs pédagogiques: [http://fr.wikipedia.org/wiki/Taxonomie_de_Bloom taxonomie de Bloom] (limiter aux niveaux 1, 2 voir 3)
* [[MOOC:Stats Compagnon| Statistiques sur le document compagnon]]

= Outils =
* [http://wiki.g6.asso.fr/index.php?title=Annuaire_Intervenants_MOOC Annuaire Intervenants MOOC]
* [https://docs.google.com/spreadsheets/d/1xwPM_2cbo_Fw9iTS14YyU2VpbufOT0v8NVUMRgp1I9Q/edit?usp=sharing Annuaire] (nouveau)
* Liste de diffusion [mailto:mooc-ipv6@imt-atlantique.fr mooc ipv6]
** La page d'accueil de la liste : https://listes.imt-atlantique.fr/wws/info/mooc-ipv6
** Introduction aux listes de diffusion : https://listes.imt-atlantique.fr/wws/help/introduction
* [[MOOC:Lille| Séjour à IMT Lille]]
* [http://livre.g6.asso.fr/index.php?title=Special:Search&fulltext=Search&profile=advanced Recherche sur le Wiki]
* [https://docs.google.com/document/d/1A72NHGB17awkHqUOrm-KFAjbiMb3dUdV3v-z0tRB7lA/edit Le Tableau blanc]
* [https://us04web.zoom.us/j/9708780848 Session ZOOM ]

= Archive comptes rendus de réunions =
* [[MOOC:Réunion_20201118|20201118 Point d'avancement]]
* [[MOOC:Réunion_20200615|20200615 Réunion pédago]]
* [[MOOC:Réunion_20200527|20200527 Point d'avancement]]
* [[MOOC:Réunion_20200402|20200402 Réunion pédago]]
* [[MOOC:Réunion_20200306|20200306 Réunion fin de rédaction]]
* [[MOOC:Réunion_20200212|20200212 Réunion refonte session6 2]]
* [[MOOC:Réunion_20200121|20200121 Réunion refonte session6]]
* [[MOOC:Réunion_20190927|20190927 Réunion bilan session5]]
* [[MOOC:Réunion_20190319|20190319 Réunion session5]]
* [[MOOC:Réunion_20181019|20181019 Réunion refonte]]
* [[MOOC:Réunion_20180709|20180709 Réunion bilan session 4]]
* [[MOOC:Réunion_20170306|20170306 Réunion d'avancement session3]]
* [https://docs.google.com/document/d/1hjqUmFv2WvJfgRcuBQS0mXItJRGAYqpearu2qFvCxG4/edit#heading=h.5ajsmpmo8nls 20161128 Réunion de reprise de contact]
* [https://docs.google.com/document/d/1dQn_fgq3Z8UTpW1pZ647lCisXwpU_6c-_Q0jFqNEjT8/edit#heading=h.7e8c433picx9 20160616 Réunion bilan session2]
* [[MOOC:Réunion_20160414|20160414 Réunion d'avancement2]]
* [[MOOC:Réunion_20160401|20160401 Réunion d'avancement1]]
* [[MOOC:Réunion 20160209|20160209 Réunion avant session 2]]
* [[MOOC:Réunion 20151207|20151207 Réunion bilan session1]]
* [[MOOC:Réunion 20151006|20151006 Réunion finalisation]]
* [[MOOC:Réunion 20150904|20150904 Réunion d'avancement]]
* [[MOOC:Réunion 20150311|20150311 Réunion de synchronisation]]
* [[MOOC:Réunion 20150306|20150306 Réunion d'avancement]]
* [[MOOC:Réunion 20150216|20150216 Réunion d'avancement]]
* [[MOOC:Réunion 20150203|20150203 Réunion d'avancement]]
* [[MOOC:Réunion 20150115|20150115 Réunion d'avancement]]
* [[MOOC:Réunion 20141211|20141211 Rencontre MOOC Paris]]
* [[MOOC:Réunion 20141201|20141201 Réunion d'avancement]]
* [[MOOC:Réunion 20141124|20141124 Réunion Articulation PRD/IPv6]]
* [[MOOC:Réunion 20141031|20141031 Réunion de démarrage]]

= Archives =

== Session 6 ==

==== Actions ====

* [[MOOC:Evolutions | Syllabus session 6]]
* [[MOOC:Taches Session 6| Liste des tâches]]
* [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]
* [[MOOC:Table des corrections6|Table des corrections]]

* [[MOOC:Bilan Session 6|Bilan Session 6]]

===== Animation =====

* [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/ Cours en ligne]
** [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session06 Studio]
* [[MOOC:Cahier des corrections|Cahier des corrections]]

== Session 5 ==
* [[MOOC:Session_5-Taches| Liste des tâches]]
* [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session05 Studio]
* [[MOOC:Bilan_Session5|Bilan Session 5]]
* [[MOOC:Manuel_Apprenant_Session5|archive manuel apprenant session5]]

== Session 4 ==
* [[MOOC:Bilan_Session_4]]

== Session 3 ==
* [[MOOC:Taches_Session_3]]
* [[MOOC:Matrice relecture Compagnon]]
* [[MOOC:Matrice des Quiz]]
* [[MOOC:Session3-Alignement Evaluations| Alignement Evaluations]]
* [[MOOC:Bilan_Session_3]]
* [[MOOC:Erratum_Session_3]]

=== Session 2===
* [[MOOC:Taches Session 2]]
* [[MOOC:Corrections des videos]]

=== Session 1===
* [[MOOC:Formalisation de la structure]]
* [[MOOC:Figures]]
* [[MOOC:Matrice des séquences]]
* [[MOOC:Matrice des auteurs]]
* [[MOOC:Bilan Session1]]
* [[MOOC:Cahier_des_Charges_Plateforme_Lab|Cahier des charges de la plateforme Lab]]

=Communication=
* Page d'annonce du MOOC IPv6 sur FUN : [https://www.france-universite-numerique-mooc.fr/courses/MinesTelecom/04012/session01/about Objectif IPv6 : vers l'internet nouvelle génération]
* Annonces faites par l'Université de la Réunion:
** [[MOOC:comUR | Message du 15 juillet]]
** Sur le site institutionnel : [http://www.univ-reunion.fr/actualites/ipv6-le-premier-mooc-de-luniversite-de-la-reunion/ Actualités]

* Presentation du plan: https://prezi.com/jjmq_45fjhfr/mooc-objectif-ipv6-plan-du-cours/

* Pour les avis mymooc https://www.my-mooc.com/fr/mooc/objectif-ipv6-vers-linternet-nouvelle-generation/

MOOC:Guide de rédaction

2022-03-04T09:25:55Z

Panelli: /* Erreurs communes */

> [[MOOC:Accueil|MOOC]]>[[MOOC:Gestion_de_projet|Gestion de projet]] > [[MOOC:Guide_de_rédaction |Guide de rédaction]]
----
__NOTOC__
=Structure=
Chaque activité du document compagnon doit avoir:
# '''Une introduction''': pour présenter la problématique
# '''Une conclusion''': pour rappeler les points importants à retenir de l'activité
# '''Une référence bibliographique''': les citations dans le texte
# '''Pour aller plus loin''': la liste des RFC citées dans le texte

=Terminologie=
* Noeud: Machine ou système connecté (routeur et Hôte). Utiliser à la place de machine, équipement
* Hôte ou station : système d'extrémité. Ne pas utiliser le terme de poste, terminal etc.
* Routeur: système relais
* Internet v4: Internet en IPv4
* Internet v6: Internet en IPv6
* ''Solicited Multicast Address'' : Adresse multicast de sollicitation de voisin

=Mise en forme=
* Pas de lien vers d'autres pages du wiki
* Inutile de mettre un lien sur un RFC, c'est fait automatiquement par le wiki avec la syntaxe :: RFC xxxx
* les adresses, champs d'en-tête, sont à mettre en police courrier (balise HTML <tt>tt</tt> )
* Le figures sont à numéroter. Le titre de la figure est à mettre dans le texte sous la figure. Enfin chaque figure doit être citée dans le texte. Ceci se déclare de la manière suivante:
<pre>
<center>
[[Image:42-fig1.jpg|400px|center|thumb|Figure 2: Plan de migration vers IPv6.
]]
</center>
</pre>
* Uniquement les termes anglais sont à mettre en italique, pas les abréviations anglaises qui restent en police normale. L'abréviation précède le terme entre parenthèses:
<pre>
TCP (''Transmission Control Protocol'')
</pre>
* Les RFC mis dans la section pour aller plus loin sont cité dans le texte soient par [RFC XXXX] ou par Reflist
* Pour ajouter un encadré dans le texte. L'encadré sert à apporter des précisions ou à donner des informations générales. Le template est définit sous ce lien [http://livre.g6.asso.fr/index.php?title=Template:HorsTexte Template]
<pre>
{{HorsTexte| Titre|texte.}}
</pre>
* Les commentaires de relecteur sont à mettre avec la commande note:
<pre>
{{Note|nom| commentaire}}
</pre>
* Pour ajouter un texte A faire en rouge
<pre>
{{TODO|chose à faire}}
</pre>

=Erreurs communes=
* <strike>entête</strike> => en-tête (nom masculin !)
* Ce qui suit un en-tête est la charge utile
* relais est un mot invariable (s au singulier comme au pluriel)
* interface => nom féminin
* IPv4/IPv6 => le v en minuscule
* Internet avec un grand I pour le réseau mondial (avec un petit i signifie une interconnexion de réseaux)
* MTU est féminin.
* Auto-configuration, un - après Auto
* interopérer, sans tiret
* Anglais / Français : donner le terme français et la traduction anglaise entre parenthèses et italique
** ex: Le message ICMPv6 d'annonce de voisin (''Neighbor Advertisment'')
* Lorsqu'il y a une abréviation donner l'abréviation puis la signification entre parenthèses et italique
** ex: PI (''Provider Independent'').
* RFC est masculin
* Implémentation => mise en oeuvre

== Références ==

Avec le mécanisme de génération semi-auto du document compagnon, les références sous forme d'URL apparaissent sous la forme '[x]' sans que l'ont ait la liste correspondante de ces références en fin d'activité. <br>
Il est donc plus intéressant d'utiliser le module de référence
[https://www.mediawiki.org/wiki/Template:Reflist Reflist] qui est construit sur le module [https://www.mediawiki.org/wiki/Extension:Cite Cite].

Dans le texte encadrer la référence par
<pre>
<ref> ma reference</ref>
</pre>

Ensuite, la liste des références est crée dans une page wiki par l'instruction
<pre>
<references />
</pre>

Une référence est sur le style:
Auteur, Prénom. (Année). Editeur. Titre.

Par exemple:
<pre>
<ref>Huston, G (2013). APNIC Labs. [http://labs.apnic.net/?p=335 A Primer on IPv4, IPv6 and Transition]</ref>
</pre>
donnera<ref>Huston, G (2013). APNIC Labs. [http://labs.apnic.net/?p=335 A Primer on IPv4, IPv6 and Transition]</ref>

===References===
<references />

=Pour aller plus loin=
Tous les RFC cités dans le texte doivent avoir le titre d'indiqué dans la section pour aller plus loin. Ils doivent être triés par ordre croissant de numéro. Si une analyse de Bortzmeyer existe, un lien URL doit être ajouté. Exemple:

RFC et leur analyse par S. Bortzmeyer :
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]

MOOC:Verb44

2022-03-04T09:21:21Z

Panelli: /* Conclusion */

__NOTOC__

= Activité 44 : Interopérer les applications par passerelles applicatives =

==Contexte d'utilisation==

<center>
[[image:V44-1.png|400px|thumb|center|]]
</center>

La solution NAT64 bien que fonctionnelle n'est pas universelle.
Certaines applications n'arrivent plus à communiquer lorsque leur communication passe par le NAT64. C'est le cas notamment quand le protocole applicatif utilise des adresses IP.

La solution de la passerelle applicative offre une technique d'interopérabilité moins intrusive que NAT64 au niveau de l'infrastructure de communication. En effet, déployer NAT64 demande de modifier le routage, et d'allouer des adresses.
Le déploiement du NAT64 est transparent pour les hôtes, mais nécessite des modifications au niveau du réseau.

Dans le cas du déploiement d'une passerelle applicative, nous sommes dans une situation inverse, les modifications sont à apporter uniquement, dans la configuration des hôtes.
Ainsi, il est possible avec une passerelle applicative d'avoir un déploiement progressif d'IPv6 dans le réseau sans perturber les services en place.
Enfin, dans le cas d'un client IPv4 qui se connecte à des serveurs de l'Internet IPv6, la passerelle applicative est de nos jours la seule méthode d'intér-opérabilité.
Et de manière générale, la passerelle applicative est une technique pour traiter les situations d'échec de NAT64.

==Principe des passerelles applicatives==

<center>
[[image:V44-2.png|400px|thumb|center|]]
</center>

La passerelle applicative (encore appelée ALG pour ''Application Layer Gateway'') est un nœud en double pile qui opère au niveau du protocole applicatif.
Elle reçoit ici un paquet en IPv6 qui lui a été adressé explicitement par la source.
Elle traite les données du paquet selon le protocole applicatif puis effectue un envoi vers le destinataire final.
Ce destinataire est joignable dans une autre version du protocole IP que la source.
En quelque sorte, on profite de passer par une passerelle applicative pour les besoins de l’application, pour changer de version de protocole IP

==Cas du service web==

<center>
[[image:V44-3.png|400px|thumb|center|]]
</center>

Il s'agit ici de faire communiquer des clients avec des services Web. Les clients et les serveurs utilisent une version différente du protocole IP.
La passerelle applicative utilisée dans notre illustration est un relais HTTP, qui va recevoir les requêtes, et émettre les réponses.
Lorsque le déploiement de la passerelle applicative est, du côté du client, on parle de '''proxy'''.
Elle va servir à atteindre tous les serveurs extérieurs, dont ceux qui utilisent une version IP différente du client.

Lorsque le déploiement de la passerelle applicative est, dans le réseau du serveur, on parle de '''reverse proxy'''. Elle va servir à donner accès aux contenus du serveur pour tous les clients qui n'utilisent pas la version IP du serveur.

La passerelle applicative est un moyen d'offrir un accès à des clients IPv6, sans modifier le serveur. La règle de transparence du déploiement d'IPv6, au service en place, est ainsi très bien illustrée.
* Lorsqu'un client qui est ici un navigateur web souhaite accéder à un serveur web, il envoie une requête en IPv6 au proxy.
* Le proxy reçoit cette requête, la traite, et la fait suivre en IPv4 au serveur.
* Ce dernier répond en IPv4 par un envoi à destination du proxy.
* Le proxy reçoit la réponse et la fait suivre en IPv6, au client.

Nous voyons ici, la situation où l'accès au serveur s'effectue en passant par un reverse proxy. Autrement dit, une ALG coté serveur a été installée.

* L'ALG a été enregistrée dans le DNS avec une adresse IPv6 sous le nom de exemple.org qui est le nom du service. L'adresse IPv4 du service est toujours celle du serveur.
* L'ajout du reverse proxy ne change rien pour les clients IPv4. Ceux-ci accèdent directement au serveur.
* Dans le cas d'un client IPv6, celui-ci envoie une requête pour obtenir l'adresse IPv6 du service.
* Le DNS lui répond par l'adresse du reverse proxy.
* Le client envoie en IPv6 sa requête à destination du reverse proxy.
* Celui-ci reçoit cette requête, la traite, et la fait suivre en IPv4 au serveur, qui dispose du contenu.
* Le serveur envoie la réponse au reverse proxy, en IPv4.
* Le reverse proxy disposant du contenu demandé, peut maintenant répondre en IPv6 à la requête du client.

==Conclusion==

<center>
[[image:V44-4.png|400px|thumb|center|]]
</center>

Les passerelles applicatives offrent un moyen simple d’interopérer une application entre des clients, et des serveurs qui n'utilisent pas la même version du protocole IP.
Parce qu'elles interprètent le contenu du paquet dans la couche d'application, elles sont transparentes pour l'infrastructure de communication. En effet, elles ne demandent pas de modifications au niveau du réseau.
Cependant, les passerelles applicatives introduisent un délai pour le traitement des paquets.
Elles passent mal le facteur d'échelle, et présentent un risque de congestion.
Enfin, elles se limitent aux applications conçues pour pouvoir fonctionner avec un relais intermédiaire.

MOOC:Verb44

2022-03-04T09:21:07Z

Panelli: /* Activité 44 : Inter-opérer les applications par passerelles applicatives */

__NOTOC__

= Activité 44 : Interopérer les applications par passerelles applicatives =

==Contexte d'utilisation==

<center>
[[image:V44-1.png|400px|thumb|center|]]
</center>

La solution NAT64 bien que fonctionnelle n'est pas universelle.
Certaines applications n'arrivent plus à communiquer lorsque leur communication passe par le NAT64. C'est le cas notamment quand le protocole applicatif utilise des adresses IP.

La solution de la passerelle applicative offre une technique d'interopérabilité moins intrusive que NAT64 au niveau de l'infrastructure de communication. En effet, déployer NAT64 demande de modifier le routage, et d'allouer des adresses.
Le déploiement du NAT64 est transparent pour les hôtes, mais nécessite des modifications au niveau du réseau.

Dans le cas du déploiement d'une passerelle applicative, nous sommes dans une situation inverse, les modifications sont à apporter uniquement, dans la configuration des hôtes.
Ainsi, il est possible avec une passerelle applicative d'avoir un déploiement progressif d'IPv6 dans le réseau sans perturber les services en place.
Enfin, dans le cas d'un client IPv4 qui se connecte à des serveurs de l'Internet IPv6, la passerelle applicative est de nos jours la seule méthode d'intér-opérabilité.
Et de manière générale, la passerelle applicative est une technique pour traiter les situations d'échec de NAT64.

==Principe des passerelles applicatives==

<center>
[[image:V44-2.png|400px|thumb|center|]]
</center>

La passerelle applicative (encore appelée ALG pour ''Application Layer Gateway'') est un nœud en double pile qui opère au niveau du protocole applicatif.
Elle reçoit ici un paquet en IPv6 qui lui a été adressé explicitement par la source.
Elle traite les données du paquet selon le protocole applicatif puis effectue un envoi vers le destinataire final.
Ce destinataire est joignable dans une autre version du protocole IP que la source.
En quelque sorte, on profite de passer par une passerelle applicative pour les besoins de l’application, pour changer de version de protocole IP

==Cas du service web==

<center>
[[image:V44-3.png|400px|thumb|center|]]
</center>

Il s'agit ici de faire communiquer des clients avec des services Web. Les clients et les serveurs utilisent une version différente du protocole IP.
La passerelle applicative utilisée dans notre illustration est un relais HTTP, qui va recevoir les requêtes, et émettre les réponses.
Lorsque le déploiement de la passerelle applicative est, du côté du client, on parle de '''proxy'''.
Elle va servir à atteindre tous les serveurs extérieurs, dont ceux qui utilisent une version IP différente du client.

Lorsque le déploiement de la passerelle applicative est, dans le réseau du serveur, on parle de '''reverse proxy'''. Elle va servir à donner accès aux contenus du serveur pour tous les clients qui n'utilisent pas la version IP du serveur.

La passerelle applicative est un moyen d'offrir un accès à des clients IPv6, sans modifier le serveur. La règle de transparence du déploiement d'IPv6, au service en place, est ainsi très bien illustrée.
* Lorsqu'un client qui est ici un navigateur web souhaite accéder à un serveur web, il envoie une requête en IPv6 au proxy.
* Le proxy reçoit cette requête, la traite, et la fait suivre en IPv4 au serveur.
* Ce dernier répond en IPv4 par un envoi à destination du proxy.
* Le proxy reçoit la réponse et la fait suivre en IPv6, au client.

Nous voyons ici, la situation où l'accès au serveur s'effectue en passant par un reverse proxy. Autrement dit, une ALG coté serveur a été installée.

* L'ALG a été enregistrée dans le DNS avec une adresse IPv6 sous le nom de exemple.org qui est le nom du service. L'adresse IPv4 du service est toujours celle du serveur.
* L'ajout du reverse proxy ne change rien pour les clients IPv4. Ceux-ci accèdent directement au serveur.
* Dans le cas d'un client IPv6, celui-ci envoie une requête pour obtenir l'adresse IPv6 du service.
* Le DNS lui répond par l'adresse du reverse proxy.
* Le client envoie en IPv6 sa requête à destination du reverse proxy.
* Celui-ci reçoit cette requête, la traite, et la fait suivre en IPv4 au serveur, qui dispose du contenu.
* Le serveur envoie la réponse au reverse proxy, en IPv4.
* Le reverse proxy disposant du contenu demandé, peut maintenant répondre en IPv6 à la requête du client.

==Conclusion==

<center>
[[image:V44-4.png|400px|thumb|center|]]
</center>

Les passerelles applicatives offrent un moyen simple d’inter-opérer une application entre des clients, et des serveurs qui n'utilisent pas la même version du protocole IP.
Parce qu'elles interprètent le contenu du paquet dans la couche d'application, elles sont transparentes pour l'infrastructure de communication. En effet, elles ne demandent pas de modifications au niveau du réseau.
Cependant, les passerelles applicatives introduisent un délai pour le traitement des paquets.
Elles passent mal le facteur d'échelle, et présentent un risque de congestion.
Enfin, elles se limitent aux applications conçues pour pouvoir fonctionner avec un relais intermédiaire.

MOOC:Verb43

2022-03-04T09:20:37Z

Panelli: /* Activité 43 : Inter-opérer les applications par traduction */

__NOTOC__

= Activité 43 : Interopérer les applications par traduction =

==Contexte d'utilisation==

<center>
[[image:V43-1.png|400px|thumb|center|]]
</center>

La faible migration des nœuds IPv4 vers IPv6 oblige à avoir recours à une technique de traduction pour faire interopérer un noeud en IPv6, avec un noeud en IPv4.
En effet, les nouveaux nœuds sont des clients en IPv6. La grande base des serveurs de l'Internet est restée en IPv4.
La communication par traduction vise donc à permettre à ces clients IPv6 à accéder aux services de l'Internet IPv4.

==Dispositif de traduction==

<center>
[[image:V43-2.png|400px|thumb|center|]]
</center>

Lorsque le client envoie une requête en IPv6, le traducteur va intercepter les paquets pour les traduire, et les émettre dans la version du protocole IP du destinataire final
Et quand le serveur envoie la réponse en IPv4, le traducteur change la version du protocole IP, pour correspondre à celle du client.
Ce dispositif est comparable au NAT des réseaux IPv4. Dans notre cas, ce dispositif n'effectue pas, une simple translation d'un plan d'adressage à un autre, mais une véritable traduction de l'en-tête IP. Un tel NAT est appelé NAT64.

==Principe de la traduction entre protocoles IP==

<center>
[[image:V43-3.png|400px|thumb|center|]]
</center>

La traduction entre protocoles IP comporte essentiellement 2 composants:
* une transposition protocolaire et,
* une traduction des adresses

Dans notre exemple, lorsque le paquet IPv6 est reçu, les champs de l'en-tête IPv6 (à l'exception des adresses) sont transposés dans leur équivalent dans l'en-tête du paquet IPv4.
Cette transposition est faite uniquement avec les informations contenues dans le paquet IPv6.
On parle alors, de traduction sans état.
Le paquet IPv4, une fois l'en-tête complète, et le champ de données chargé avec les données du paquet IPv6, est alors prêt à être émis pour atteindre la destination finale.

La traduction d'adresse consiste à mettre en correspondance une adresse de l'espace d'adressage IPv6 avec une adresse de l'espace d'adressage IPv4, et vice et versa, à la fois pour l'adresse source, et pour l'adresse de destination du paquet reçu par le NAT64.
Dans le réseau IPv6, la communication utilise l'adresse H6 et l'adresse N6. Ces adresses sont mises en correspondance, respectivement avec N4 et H4 pour les communications dans le réseau IPv4
Ceci veut dire, que l'adresse N6 sert à identifier le noeud d'adresse H4, dans le réseau IPv6. Et de manière symétrique l'adresse N4 sert à identifier le noeud d'adresse H6, dans le réseau IPv4.

La correspondance entre une adresse IPv4 avec une adresse IPv6 est évidente lorsque l'adresse IPv6 embarque l'adresse IPv4. En effet, représenter une adresse IPv4 dans l’espace d’adressage IPv6 est simple, car ce dernier est assez grand pour contenir l’ensemble des adresses IPv4. Pour ce faire, une adresse IPv6 va être créée pour inclure l'adresse IPv4.

La méthode de création consiste, à inclure les 32 bits de l'adresse IPv4, à la suite d'un préfixe IPv6, qui dans notre schéma est un préfixe réservé à l'usage de la traduction.
Une traduction d'adresse, qui utilise une adresse IPv6 embarquant une adresse IPv4, s'effectue '''sans état'''.

Lorsque l'adresse IPv6 n'embarque pas l'adresse IPv4, alors mettre en correspondance une adresse IPv6 avec une adresse IPv4, demande une traduction d'adresse '''avec état'''.

La mise en correspondance de l'adresse IPv6 avec une adresse IPv4 est faite dynamiquement, par le traducteur.
Comme, il n'y aura pas assez d'adresses IPv4 pour les nœuds IPv6, le traducteur utilise, en plus le numéro de port pour reconnaitre les nœuds IPv6.

Le traducteur retient, dans un état, cette association d'adresses, et de ports entre IPv4, et IPv6.

==Fonctionnement de NAT64/DNS64==

<center>
[[image:V43-4.png|400px|thumb|center|]]
</center>

Nous allons voir ici un exemple de l'utilisation de NAT64 dans un réseau de mobiles. Le réseau de mobiles a été déployé avec IPv6 uniquement.
* Un client, ici, un mobile souhaite accéder à un service qui est resté en IPv4.
* Le mobile envoie, au serveur DNS local, ici, DNS64, une requête de résolution du serveur old.org.
* Le DNS64 demande l'adresse IPv4 au système DNS.
* Il obtient en réponse l'adresse IPv4 demandée.
* Le DNS64 se charge de transformer, cette adresse, en une adresse IPv6, et l'envoie au client.
* A cet instant, le mobile connait l'adresse du serveur old.org. Il l'a connait au moyen d'une adresse IPv6 embarquant l'adresse IPv4. Maintenant, le client IPv6 est en mesure d'envoyer sa requête.
* Cette requête va être acheminée jusqu'au NAT64, qui va traduire le paquet IPv6 en un paquet IPv4.
* La requête continue son acheminement en IPv4 pour atteindre le serveur demandé.

==Conclusion==

<center>
[[image:V43-5.png|400px|thumb|center|]]
</center>

La solution de traduction NAT64 trouve son intérêt pour des nœuds IPv6. Ils peuvent accéder à des contenus accessibles uniquement en IPv4.

Il peut paraitre contradictoire d'utiliser IPv6 pour se passer de la traduction, pour en fait retrouver des traducteurs dans les communications. Il est important de noter, que cette solution se veut transitoire, au contraire d'IPv4.

Le NAT64 est le composant de migration.
En effet, il est intéressant aujourd'hui de pouvoir déployer des réseaux IPv6 uniquement à la place de réseaux IPv4 privés.
C'est le choix qu'ont fait certains opérateurs de réseaux de mobiles.

L'utilisation de NAT64 a montré, que c'était une solution fonctionnelle.
Ça marche, sauf pour les applications, qui font référence à l'adresse IPv4.

MOOC:Compagnon Act04-f

2022-03-01T09:29:21Z

Panelli: /* Une cohabitation forcée */

__NOTOC__




= Activité 04 : Pourquoi IPv6 ? =

== Motivations ==

Le problème de pénurie des adresses Internet est principalement dû à l'explosion de la demande qui dépasse largement la capacité d'adressage IPv4. Ce problème qui est devenu critique ces dernières années, milite pour l’adoption rapide d’IPv6. En effet, il faut aujourd'hui un grand espace d'adressage pour adresser tous les appareils connectés et par la suite, les futurs objets connectés issus des applications IoT. Dépasser la pénurie d'adresses, c'est aussi ouvrir la voie à de nouveaux services, à de nouveaux acteurs innovants, c'est créer de nouveaux marchés pour de nouveaux besoins. Le passage à IPv6 devient une nécessité car, en attribuant une adresse à chaque nœud du réseau, la connectivité en IPv6 retrouve les principes qui ont fait le succès du fonctionnement de l'Internet.


La technologie de l'infrastructure de communication retrouve sa simplicité originelle. Il n'est pas soutenable que la croissance du réseau s'effectue avec une complexité croissante comme avec IPv4. Tout ceci est bien connu et cette évolution est qualifiée par "non passage au facteur d'échelle" (''not scalable''). Ainsi, avec cette simplicité retrouvée, de nouveaux champs d'application s'ouvrent à l'Internet en IPv6. Le [RFC 7368] en donne une illustration avec la domotique.

En plus de la simplicité retrouvée, IPv6 apporte de nouvelles fonctionnalités, comme la configuration automatique d'un réseau. En IPv4, chaque équipement doit se voir attribuer une adresse et obtenir sa configuration depuis un serveur qui reste à gérer. Avec IPv6, le réseau peut se gérer uniquement au niveau des routeurs, les stations construisant leurs adresses automatiquement. Ce qui est très intéressant lorsque le réseau comporte un grand parc de machines.

Nous allons introduire les points clés de la nouvelle version du protocole d'interconnexion IP : le protocole IPv6. Nous expliquerons pourquoi il y a beaucoup plus d'adresses et comment le protocole IP a été simplifié et modernisé. Les deux protocoles étant différents, le passage d'IPv4 à IPv6 a fait l'objet de scénarios spécifiés dans des RFC. Un grand nombre d'équipements et de services reposent toujours sur IPv4 et une cohabitation s'est installée pour encore de nombreuses années. Néanmoins, IPv6 est un passage obligé pour l'Internet du 21<sup>e</sup> siècle.

== IPv6 : une nouvelle version d'IP ==

Depuis le premier RFC sur IPv6 publié en décembre 1995, la version IPv6 a quitté les laboratoires. L'étape de standardisation des protocoles de base de IPv6 (''core specs'') est achevée depuis le début des années 2000.
La nouvelle version d'IP reprend ses principes fondateurs : encapsulation des données dans des paquets, adresses source et destination dans l'en-tête, transfert en mode datagramme, routage paquet par paquet.

Le réseau utilise des équipements intermédiaires simples et transparentes aux données transférées. Il n'effectue aucune reprise sur erreurs et tout le contrôle est reporté sur les extrémités dans d'autres protocoles. L'adressage est toujours hiérarchique mais de nouveaux niveaux sont ajoutés à la demande.

Deux points clés permettent à IPv6 de résoudre les problèmes que nous avons évoqués dans les activités précédentes :

* IPv6 offre une adresse plus longue qui passe de 32 bits à 128 bits. Cette capacité immense va résoudre la pénurie à très long terme ;
* les concepteurs d'IPv6 ont voulu moderniser le protocole par la même occasion pour prendre en compte de nouveaux besoins qui n'avaient pas été envisagés dans les années 70-80.

Par exemple, il n'avait pas été imaginé le développement de la diffusion de chaînes de télévision sur Internet. Dans IPv6, la diffusion à un groupe de récepteurs, le ''multicast'', a été défini dès le départ.

=== Un système d'adressage avec une capacité immense ===

L'espace d'adressage IPv6 a une capacité immense. Une adresse IPv6 est longue de 128 bits (16 octets), contre 32 bits pour IPv4. On dispose ainsi d'environ 3,4 × 10<sup>38</sup> adresses (soit plus de 340 sextillions). Pour reprendre l'image usuelle, on aurait plus de 667 millions d'adresses IPv6 par millimètre carré de surface terrestre.

La notation d'une adresse IPv6 se fait maintenant en hexadécimal, codé sur 16 bits. Une adresse IPv6 est alors représenté par 8 mots de 2 octets séparés par un ":", comme le montre l'exemple de la figure 2.

<center>
[[Image:04-fig1.png|500px|thumb|center|Figure 1 : Exemple d'adresse IPv6 notée en héxadécimal.]]
</center>

Le format de l'adresse est hiérarchique avec de multiples niveaux. L'opérateur dispose d'un bloc d'adresses plus long qui lui donne plus de liberté pour allouer des sous-blocs. On peut découper par exemple l'adresse en 4 champs qui sont :
* le préfixe FAI ;
* le préfixe de réseau ;
* le préfixe de sous-réseau ;
* et l'adresse hôte.

<center>
[[Image:04-fig2.png|500px|thumb|center|Figure 2 : Format de l'adresse IPv6.]]
</center>

En IPv6, l'auto-configuration d'adresse permet à un hôte d'utiliser son adresse physique ou MAC pour créer son adresse réseau. Pour réaliser la transition en douceur, il est aussi possible de dériver l'adresse IPv6 de l'adresse IPv4. De nouvelles fonctionnalités définissent des adresses génériques pour, par exemple, trouver immédiatement le serveur DNS sur un réseau, ou n'importe quel autre service.

=== Une simplification des fonctions d’IP ===

La conception d'IPv6 est aussi l'occasion de dépoussiérer le protocole. Fort de l'expérience acquise avec IPv4, certaines fonctions d'IP on été redéfinies et optimisées, d'autres ont été supprimées.

Ainsi, la protection des erreurs du paquet IPv4 par un ''checksum'' est finalement inutile puisque déjà réalisée au niveau liaison ; le champ ''checksum'' n'est plus présent dans l'en-tête IPv6.

La fonction de fragmentation d’un paquet par le routeur a été elle aussi supprimée. Cette fonction a pour but d’adapter la taille du paquet à celle de la trame du réseau suivant. Cela signifie que lorsque le routeur veut envoyer un paquet qui est plus grand que la taille de la trame, il doit fragmenter ce paquet et ainsi l’envoyer dans plusieurs trames consécutives. Les différents fragments sont identifiés pour permettre en réception de reconstituer le paquet initial. La fragmentation a de multiples inconvénients qui sont l’accroissement du temps de traitement du paquet par le routeur, une probabilité plus importante de perte de paquets puisque un seul frgment perdu entraîne la perte de tout le paquet et enfin, en réception, la mémorisation des fragments, leur éventuel remise en ordre avant la livraison à la couche supérieure. Pour éviter la fragmentation par les routeurs, le protocole IPv6 préconise d'apprendre la taille minimale de paquet supportée '''sur tout le chemin''' et ainsi, d'envoyer des paquets de la bonne taille. Les trois champs de l’en-tête dédiés à cette fonction ont donc été supprimés.

Un inconvénient d'IPv4 est qu'il n'y a aucune relation entre les adresses de niveau réseau et de niveau liaison. Or l'adresse physique est nécessaire pour transmettre la trame qui contient le paquet. Avec IPv4, il faut donc chercher et récupérer cette adresse physique avant d'encapsuler le paquet dans la trame. Pour éviter cette recherche, IPv6 fournit l'auto-configuration d'adresse réseau à partir de l'adresse physique.

Le protocole IPv4 ayant été conçu il y a 40 ans, de nouveaux usages sont apparus qu'il a fallu ajouter de manière artificielle. Dans IPv6, il sera possible d'ajouter de nouvelles fonctionnalités assez facilement grâce aux extensions d'en-tête.

== De IPv4 à IPv6 ==

=== Une transition pas si simple ===

IPv4 et IPv6 sont des protocoles différents : les adresses ainsi que le format des paquets n'ont pas la même structure. De fait, les deux technologies vont cohabiter sur Internet, chacune dans un plan d'adressage différent. Ceci a pour conséquence que la communication entre un hôte IPv4 et un hôte IPv6 ne peut pas se faire directement. Pour connecter tous les utilisateurs de manière transparente, les routeurs et les hôtes devront avoir une connectivité IPv4 et IPv6. On parle de double pile. Les équipements disposent alors à la fois d'une adresse IPv4 et d'une adresse IPv6.

<center>
[[Image:04-fig3.png|500px|thumb|center|Figure 3 : Scénario de transition IPv6 avec routeurs double pile.]]
</center>

Lorsqu'une des connectivités est manquante, il est possible de recourir à des solution de tunnels. Un tunnel permet à deux hôtes IPv4 de communiquer au travers d'un réseau IPv6, ou inversement. Cependant, il faut noter que le recours à un mécanisme de tunnels est complexe et nuit aux performances.

D'autres scénarios de transition ont été étudiés et sont spécifiés dans plusieurs RFC.

=== Une cohabitation forcée ===

Le premier standard IPv6 date de 1995 et a été amélioré et complété durant une dizaine d'années. Depuis, la transition vers IPv6 n'est toujours pas finie alors même que les opérateurs ont quasiment tous épuisé leurs adresses IPv4.

En France, dans son baromètre annuel de la transition vers IPv6 <ref>Baromètre annuel de la transition vers IPv6 en France (Nov. 2021) [https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transition-ipv6/barometre-annuel-de-la-transition-vers-ipv6-en-france.html]</ref>, l'ARCEP pointe les nombreux freins au déploiement généralisé d'IPV6 (voir figure.4). Les causes sont multiples car cette transition nécessite des compétences techniques et des ressources adaptées. C'est un vrai projet. Et ce rapport met en évidence le rôle joué dans cette transition par les multiples acteurs de l'Internet : fournisseurs d'accès, hébergeurs de contenus, opérateurs mobiles, équipementiers, services DNS, réseau de transit et terminaux.

<center>
[[Image:04-fig4-b.png|500px|thumb|center|Figure 4 : Etat de la transition vers IPv6 selon les acteurs [ARCEP].]]
</center>

La figure 4, tirée du rapport de l'ARCEP, montre l'état d'avancement de la transition IPV6 au niveau des différents acteurs de l'Internet. Les équipementiers (ou fabricants de routeurs), les systèmes d'exploitation et les terminaux ont achevé leur mise en conformité avec les standards d'IPv6. Pour d'autres acteurs, comme les opérateurs, l'adoption d'IPv6 est plus longue. Carton rouge aux hébergeurs dont l'adoption d'IPv6 reste encore assez faible.
Sur le plan international, la situation est aussi différente selon les pays. Les Etats-unis, le Canada et quelques pays d'Europe ont largement déployé IPv6. Cependant, en majorité, les pays sont encore très faiblement impliqués comme le montre la figure 5.

<center>
[[Image:04-fig5.png|500px|thumb|center|Figure 5 : Carte de l'adoption d'IPv6 par CISCO.]]
</center>

En 2022, l'usage d'IPv6 vu par les serveurs de Google est proche de 40 %. La figure 6 montre l'évolution des usages<ref>Google. Statistics. [http://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption IPv6 Adoption]</ref>. Cette courbe montre un quasi-doublement de l'adoption d'IPv6 tous les ans depuis 2010.
Les utilisateurs de Google peuvent émettre des requêtes en IPv6 s'ils ont un accès IPv6 offert par leur fournisseur d'accès à Internet. En aout 2016, aux USA, IPv6 représente plus de la moitié du trafic mobile vers Facebook<ref>Col P. (2016) ZDNet. [http://www.zdnet.fr/actualites/ipv6-represente-plus-de-la-moitie-du-trafic-mobile-vers-facebook-aux-usa-39840834.htm IPv6 représente plus de la moitié du trafic mobile vers Facebook aux USA]</ref>.
<center>
[[Image:Google-2022.png|500px|thumb|center|Figure 6 : Évolution du pourcentage de requêtes reçues en IPv6 par Google en 2022.]]
</center>

La figure 7<ref>RIPE NCC. [http://v6asns.ripe.net/v/6?s=_ALL;s=_RIR_RIPE_NCC;s=FR;s=DE;s=GB;s=US;s=JP IPv6 Enabled Networks]</ref> montre le pourcentage des organisations annonçant un préfixe IPv6. L'Europe, de manière générale, est active dans le déploiement d'IPv6 et la Belgique en particulier <ref>Cole, P. (2016). ZDnet. [http://www.zdnet.fr/actualites/la-belgique-championne-du-monde-d-ipv6-bien-loin-devant-la-france-39839252.htm La Belgique championne du monde d'IPv6, bien loin devant la France !]</ref>. Pour suivre l'évolution de l'adoption d'IPv6, la page web de ''world ipv6 launch'' référence les mesures faites par différents opérateurs<ref>World IPv6 Launch [http://www.worldipv6launch.org/measurements/ IPv6 Measurements]</ref>.

<center>
[[Image:Ipv6-usable-2022.png|500px|thumb|center|Figure 7 : Évolution du pourcentage d'organisations annonçant au moins un préfixe IPv6 par région.]]
</center>

== IPv6 : un passage obligé ==

Restons optimistes cependant car les nouveaux services ou les nouveaux usages se tournent de plus en plus vers IPv6 car ils ne trouvent pas dans IPv4 les solutions techniques nécessaires à leur développement.

Les distributeurs de contenus qui déploient une infrastructure de caches répartis sur tout l'Internet ont besoin de beaucoup de flexibilité, de beaucoup de bande passante et d'une latence faible. Les nouveaux réseaux d'accès sont de plus en plus en IPv6. Enfin, l'Internet des objets, les villes intelligentes ou les réseaux de véhicules ne peuvent se développer qu'en IPv6.

L'adoption d'IPv6 est aussi une question de formation. Le protocole IPv6 n'est plus au stade expérimental ; il est indispensable pour un fonctionnement normal de l'Internet. Nous entendons par "normal", un fonctionnement respectant les principes fondateurs de l'Internet, dont celui du "bout-en-bout". Si les principes de ces deux versions d'IP sont très similaires, IPv4 adopte de plus en plus des principes non conventionnels pour continuer à fonctionner.

L'apprentissage du fonctionnement de l'Internet doit se faire de nos jours principalement avec IPv6, et accessoirement avec IPv4. Il faut rendre banale la nouvelle version du protocole IP.
Dans un article<ref>Huston, G. (2011). Cisco Internet Protocol Journal, Vol. 14, No. 1, pp. 14-21, March. [http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_14-1/ipj_14-1.pdf Transitional Myths]</ref>, Geof Huston dresse une liste de fausses assertions et de rumeurs pour justifier de ne pas commencer le travail de migration vers IPv6. Si ces fausses assertions circulent, elles démontrent à quel point le besoin de formation et d'information sur la situation de l'Internet est nécessaire. Nous espérons que ce cours contribuera à combler ce manque.

== Conclusion ==

Pour conclure, l'heure de la pénurie d'adresses IPv4 a sonné depuis quelques années et IPv6 est un passage obligé pour développer les nouveaux usages et simplifier le fonctionnement du réseau. IPv6 est le protocole de l’Internet du 21<sup>e</sup> siècle. Il est incontournable. L'IoT (''Internet of Things'') et les nouveaux usages seront les moteurs de son déploiement massif dans les dix prochaines années. Comme il modernise effectivement IPv4, il nécessite une étude approfondie de ses mécanismes de fonctionnement pour faciliter son appropriation par l'ensemble des acteurs impliqués dans un monde de plus en plus numérique.

IPv6 permet de retrouver les principes qui ont fait le succès de l'Internet comme, notamment, une connectivité simplifiée. Il est admis aujourd'hui qu'IPv6 est indispensable pour le développement des services innovants.

File:V44-4.png

2022-03-01T07:34:10Z

Panelli:

File:V44-3.png

2022-03-01T07:33:16Z

Panelli:

File:V44-1.png

2022-03-01T07:31:37Z

Panelli:

File:V44-2.png

2022-03-01T07:30:02Z

Panelli:

File:V43-3.png

2022-03-01T07:26:57Z

Panelli:

File:V43-2.png

2022-03-01T07:15:24Z

Panelli:

File:V43-5.png

2022-03-01T07:14:10Z

Panelli:

File:V43-4.png

2022-03-01T07:07:28Z

Panelli:

File:V43-1.png

2022-03-01T07:05:40Z

Panelli:

File:V42-6.png

2022-03-01T06:54:41Z

Panelli:

File:V42-5.png

2022-03-01T06:53:53Z

Panelli:

File:V42-4.png

2022-03-01T06:52:28Z

Panelli:

File:V42-3.png

2022-03-01T06:50:43Z

Panelli:

File:V42-2.png

2022-03-01T06:49:37Z

Panelli:

File:V42-1.png

2022-03-01T06:48:43Z

Panelli:

File:V41-6.png

2022-03-01T06:28:13Z

Panelli:

File:V41-5.png

2022-03-01T06:26:49Z

Panelli:

File:V41-4a.png

2022-03-01T06:25:35Z

Panelli:

MOOC:Verb41

2022-03-01T06:23:38Z

Panelli: /* Déploiement de la double pile */

__NOTOC__

==Introduction==

<center>
[[image:V41-1.png|400px|thumb|center|]]
</center>

Le déploiement IPv6 dans un réseau doit se faire selon de bonnes pratiques comme :

* Ne pas casser ou perturber ce qui fonctionne en IPv4. IPv6 s'ajoute à l'existant, mais ne remplace pas l'existant. Le déploiement d'IPv6 est un processus progressif, et additionnel.

* Transparent à l'utilisation ou indolore à l'utilisateur. Ce dernier ne doit constater aucune dégradation du service de communication.

* Viser des améliorations en terme, de simplicité, de gestion et de performance du réseau ou, pire, que cette dernière soit équivalente à celle obtenue en IPv4. On doit même constater un meilleur fonctionnement du réseau, afin d'encourager, et de motiver au passage à IPv6.

* Maintenir la connectivité avec l'Internet IPv4. IPv6 est une évolution de l'Internet, et ne doit pas être vue comme un moyen de faire un Internet parallèle.

Nous allons voir maintenant comment mettre en oeuvre ces bonnes pratiques, avec d'abord la présentation de la technique de la double pile, puis les étapes de déploiement d'IPv6 dans un réseau existant, et enfin les problèmes qui peuvent potentiellement survenir lors de ce déploiement.

==Technique de la double pile==

<center>
[[image:V41-2.png|400px|thumb|center|]]
</center>

Le premier mécanisme d'intégration recommandé repose sur la technique dite de la double pile.
Cette technique consiste à configurer à la fois la pile protocolaire IPv4 et la pile protocolaire IPv6 au sein d'un même noeud.
Ainsi, le noeud est capable de communiquer dans les 2 versions du protocole IP.
Il est en quelque sorte bilingue. Il parle le langage de son correspondant :

* Lorsque l'adresse IP du correspondant appartient à l'espace d'adressage IPv4, la communication s'effectue avec des paquets IPv4.
* Et quand l'adresse IP du correspondant appartient à l'espace d'adressage IPv6, la communication s'effectue en utilisant IPv6.

Lorsque le serveur est lui-même en double pile, le client commencera par une communication en IPv6, Si sa tentative échoue, il basculera sur une communication en IPv4.

Dans le cas d'un routeur, celui-ci possède une table de routage pour chaque version du protocole.
Le routeur est ainsi capable de relayer à la fois les paquets IPv6 et IPv4.
De cette façon, IPv4 et IPv6 co-existe sur la même infrastructure. Autrement dit IPv6 n'a pas besoin d'une infrastructure dédiée.

Maintenant que nous avons identifié une technique d'intégration d'IPv6 à un réseau existant, reste le problème de la méthode du déploiement d'IPv6. Par quel bout attaquer le problème ?

==Etude et préparation==

<center>
[[image:V41-3.png|400px|thumb|center|]]
</center>

Déployer IPv6 dans un réseau, c'est bien plus qu'un changement de tuyau. Cela touche tout le système d'information. On ne passe pas d'IPv4 à IPv6, comme on change de version dans un logiciel. Il faut mettre à jour tout le réseau, et toutes les applications. L'intégration d'IPv6 doit se faire avec méthode, et selon un mode projet, en suivant des étapes planifiées.

La première étape commence par une étude, et un inventaire de l'existant, afin d'identifier les points qui vont poser problème. Il n'est pas question de changer tous les équipements.
Il faut donc identifier ceux qui disposent d'IPv6.
Pour les autres, qui ne disposent pas d'IPv6, une mise à jour peut être suffisante. Il ne faut pas oublier qu'IP n'est que du logiciel.
La vérification de la disponibilité d'IPv6 peut être aussi simple, que vérifier qu'une interface réseau possède l'adresse auto-configurée de portée locale au lien.

Cependant l'adresse de portée locale au lien n'est pas suffisante.
Pour des communications passant par des routeurs, il faut une adresse unicast routable.
Pour cela, il faut constituer une adresse à partir d'un préfixe public dit GUA.
Le préfixe GUA est indispensable si le réseau est destiné à être interconnecté à l'Internet.
Ensuite, il faut définir un préfixe local selon un plan d'adressage reposant sur le champ SID.
Le préfixe public complété par le préfixe local va constituer un préfixe réseau de 64 bits attribué à un lien.
C'est en combinant ce préfixe sur 64 bits et un identifiant sur 64 bits qu'une adresse IPv6 unicast est composée.

==Déploiement de la double pile==

<center>
[[image:V41-4a.png|400px|thumb|center|]]
</center>

Une fois le plan d'adressage défini, il reste à distribuer les adresses aux noeuds. Ceci va s'effectuer, par la configuration en double pile, des équipements existants.

Il s'agit cette fois de configurer en IPv6 les routeurs, les serveurs, et les postes de travail. Comme il est peut probable que toutes les applications métiers soient capables de fonctionner en IPv6. Le réseau va rester mixte.
A ce stade, il ne faut pas oublier d'intégrer dans l'annuaire du domaine, les adresses IPv6 allouées.
Des nouveaux terminaux pourront apparaitre, et fonctionner en IPv6 nativement, tout en inter-opérant avec l'existant passé en double pile.
On peut rappeler ici, la capacité d'IPv6 à se répandre facilement sur les terminaux à l'aide de l'auto-configuration dite, sans état.

Le déploiement d'IPv6 pour les applications consiste, à ne pas avoir une version de l'application par protocole. Au contraire, la même application doit aussi bien fonctionner, avec IPv4, qu'avec IPv6.
Ainsi, quel que soit le protocole IP, celui-ci est transparent au niveau de l'utilisateur, et de l'application.

Pour avoir des applications qui fonctionnent à la fois en IPv4, et en IPv6, il faut que les applications utilisent un format d'adresse sur 128 bits, autrement dit compatible à IPv6.
La version du protocole utilisée dépendra alors de l'adresse de destination.
Lorsque l'adresse de destination est une adresse IPv6 contenant une adresse IPv4, la communication va s'effectuer en utilisant des paquets IPv4.
Et lorsque l'adresse de destination contient bien une adresse IPv6, la communication va s'effectuer par des paquets IPv6.
On voit, que la même application utilise la double pile, et que le choix de la pile est fait en fonction de la version de l'adresse du correspondant.

Soulignons que le développement d'application doit se faire de nos jours exclusivement avec le format d'adresse pour IPv6. Ainsi l’application est compatible avec IPv6, et elle reste toujours utilisable dans un environnement IPv4.

==Problèmes liés au déploiement d'IPv6==

Le déploiement d'IPv6 dans un réseau existant peut amener à des dégradations de service, si des précautions ne sont pas prises. C'est ce que nous allons voir maintenant.

<center>
[[image:V41-5.png|400px|thumb|center|]]
</center>

Le premier problème porte sur la '''phase d'établissement de connexion'''.
Les temps de réponse pour joindre un serveur peut avoir significativement augmenté tout du moins assez pour agacer l'utilisateur. Voyons le problème en détail.

Un client en double pile souhaite accéder à un serveur.
Après interrogation du service de nommage, il obtient les 2 adresses du serveur qui est lui aussi en double pile.
Conformément aux préconisations, le client demande de préférence l'établissement d'une connexion TCP en utilisant IPv6.
IPv6 ayant potentiellement des liens à base de tunnel IPv4, a une connectivité plus fragile. Il se peut que le serveur soit non joignable.
Après plusieurs tentatives infructueuses, qui auront pris de très nombreuses secondes, le client essaye donc avec l'adresse IPv4 et là, la connexion s'établit dans un temps normal.
Devant ce problème, la méthode va consister à tenter la connexion en IPv6 dans un délai très court (de l'ordre de 500 millisecondes), et de passer à IPv4 au plus vite en cas d'échec.

Le second problème est lié à la '''taille des paquets IP'''.
La taille maximale des paquets IPv6 est souvent plus limitée que pour celle pour IPv4, du fait d'un usage des tunnels plus fréquent.
Le client arrive à établir la connexion avec le serveur.
Et tant que les échanges utilisent des petits paquets tout se passe bien.
Dès qu'un paquet de taille supérieure à la taille maximale du paquet permis par le chemin est envoyé. Celui-ci est jeté, du fait qu'un routeur IPv6 ne fait pas de fragmentation.
Le routeur qui supprime le paquet signale à la source, par un message ICMP, cette anomalie de taille.
Mais comme les messages ICMP sont souvent bloqués par des administrateurs réseaux maladroits, il n'y aura pas de fragmentation faite par la source.
Au final, une connexion est établie, mais aucune donnée ne pourra être échangée.
La solution proposée consiste à ce que, TCP surveille la taille des paquets perdus, et que les retransmissions s'effectuent avec des tailles de paquet de plus en plus petites, pour finir par correspondre à la taille maximale du paquet permis par le chemin.

Enfin, un autre problème lié aussi au tunnel, porte sur '''l'interactivité dégradée'''.
Comme la connectivité IPv6 comporte souvent des tunnels.
Les tunnels peuvent être de longueur importante ajoutant des délais au temps de transfert du paquet.
Ainsi, le chemin entre un client et un serveur en IPv6 peut être bien plus long, que si la communication avait été faite en IPv4.
La solution n'est pas au niveau de l'application, elle réside dans la constitution des tunnels. Ceux-ci doivent être les plus courts possible.

==Conclusion==

<center>
[[image:V41-6.png|400px|thumb|center|]]
</center>

La double pile permet la coexistence d'IPv6 avec IPv4 dans le même réseau.
Au commencement, IPv4 reste fonctionnel, et IPv6 ne risque pas de compromettre le bon fonctionnement des services.

Le déploiement d'IPv6 s'effectue progressivement, et constitue bien une extension à IPv4 plutôt qu'un remplacement. Autrement dit, IPv6 est une évolution d'IPv4, et non le moyen de faire un Internet parallèle, et disjoint de l'existant.

Il n'en reste pas moins, que la double pile reste transitoire, et que la présence d'IPv4 oblige à prendre des précautions pour éviter une perte de performance du service fourni par IPv6.

Le service de communication en IPv6 est appelé à s'améliorer avec la disparition progressive d'IPv4.

File:V41-4.png

2022-03-01T06:22:04Z

Panelli:

MOOC:Verb41

2022-03-01T06:18:02Z

Panelli: /* Introduction */

__NOTOC__

==Introduction==

<center>
[[image:V41-1.png|400px|thumb|center|]]
</center>

Le déploiement IPv6 dans un réseau doit se faire selon de bonnes pratiques comme :

* Ne pas casser ou perturber ce qui fonctionne en IPv4. IPv6 s'ajoute à l'existant, mais ne remplace pas l'existant. Le déploiement d'IPv6 est un processus progressif, et additionnel.

* Transparent à l'utilisation ou indolore à l'utilisateur. Ce dernier ne doit constater aucune dégradation du service de communication.

* Viser des améliorations en terme, de simplicité, de gestion et de performance du réseau ou, pire, que cette dernière soit équivalente à celle obtenue en IPv4. On doit même constater un meilleur fonctionnement du réseau, afin d'encourager, et de motiver au passage à IPv6.

* Maintenir la connectivité avec l'Internet IPv4. IPv6 est une évolution de l'Internet, et ne doit pas être vue comme un moyen de faire un Internet parallèle.

Nous allons voir maintenant comment mettre en oeuvre ces bonnes pratiques, avec d'abord la présentation de la technique de la double pile, puis les étapes de déploiement d'IPv6 dans un réseau existant, et enfin les problèmes qui peuvent potentiellement survenir lors de ce déploiement.

==Technique de la double pile==

<center>
[[image:V41-2.png|400px|thumb|center|]]
</center>

Le premier mécanisme d'intégration recommandé repose sur la technique dite de la double pile.
Cette technique consiste à configurer à la fois la pile protocolaire IPv4 et la pile protocolaire IPv6 au sein d'un même noeud.
Ainsi, le noeud est capable de communiquer dans les 2 versions du protocole IP.
Il est en quelque sorte bilingue. Il parle le langage de son correspondant :

* Lorsque l'adresse IP du correspondant appartient à l'espace d'adressage IPv4, la communication s'effectue avec des paquets IPv4.
* Et quand l'adresse IP du correspondant appartient à l'espace d'adressage IPv6, la communication s'effectue en utilisant IPv6.

Lorsque le serveur est lui-même en double pile, le client commencera par une communication en IPv6, Si sa tentative échoue, il basculera sur une communication en IPv4.

Dans le cas d'un routeur, celui-ci possède une table de routage pour chaque version du protocole.
Le routeur est ainsi capable de relayer à la fois les paquets IPv6 et IPv4.
De cette façon, IPv4 et IPv6 co-existe sur la même infrastructure. Autrement dit IPv6 n'a pas besoin d'une infrastructure dédiée.

Maintenant que nous avons identifié une technique d'intégration d'IPv6 à un réseau existant, reste le problème de la méthode du déploiement d'IPv6. Par quel bout attaquer le problème ?

==Etude et préparation==

<center>
[[image:V41-3.png|400px|thumb|center|]]
</center>

Déployer IPv6 dans un réseau, c'est bien plus qu'un changement de tuyau. Cela touche tout le système d'information. On ne passe pas d'IPv4 à IPv6, comme on change de version dans un logiciel. Il faut mettre à jour tout le réseau, et toutes les applications. L'intégration d'IPv6 doit se faire avec méthode, et selon un mode projet, en suivant des étapes planifiées.

La première étape commence par une étude, et un inventaire de l'existant, afin d'identifier les points qui vont poser problème. Il n'est pas question de changer tous les équipements.
Il faut donc identifier ceux qui disposent d'IPv6.
Pour les autres, qui ne disposent pas d'IPv6, une mise à jour peut être suffisante. Il ne faut pas oublier qu'IP n'est que du logiciel.
La vérification de la disponibilité d'IPv6 peut être aussi simple, que vérifier qu'une interface réseau possède l'adresse auto-configurée de portée locale au lien.

Cependant l'adresse de portée locale au lien n'est pas suffisante.
Pour des communications passant par des routeurs, il faut une adresse unicast routable.
Pour cela, il faut constituer une adresse à partir d'un préfixe public dit GUA.
Le préfixe GUA est indispensable si le réseau est destiné à être interconnecté à l'Internet.
Ensuite, il faut définir un préfixe local selon un plan d'adressage reposant sur le champ SID.
Le préfixe public complété par le préfixe local va constituer un préfixe réseau de 64 bits attribué à un lien.
C'est en combinant ce préfixe sur 64 bits et un identifiant sur 64 bits qu'une adresse IPv6 unicast est composée.

==Déploiement de la double pile==

<center>
[[image:V41-4.png|400px|thumb|center|]]
</center>

Une fois le plan d'adressage défini, il reste à distribuer les adresses aux noeuds. Ceci va s'effectuer, par la configuration en double pile, des équipements existants.

Il s'agit cette fois de configurer en IPv6 les routeurs, les serveurs, et les postes de travail. Comme il est peut probable que toutes les applications métiers soient capables de fonctionner en IPv6. Le réseau va rester mixte.
A ce stade, il ne faut pas oublier d'intégrer dans l'annuaire du domaine, les adresses IPv6 allouées.
Des nouveaux terminaux pourront apparaitre, et fonctionner en IPv6 nativement, tout en inter-opérant avec l'existant passé en double pile.
On peut rappeler ici, la capacité d'IPv6 à se répandre facilement sur les terminaux à l'aide de l'auto-configuration dite, sans état.

Le déploiement d'IPv6 pour les applications consiste, à ne pas avoir une version de l'application par protocole. Au contraire, la même application doit aussi bien fonctionner, avec IPv4, qu'avec IPv6.
Ainsi, quel que soit le protocole IP, celui-ci est transparent au niveau de l'utilisateur, et de l'application.

Pour avoir des applications qui fonctionnent à la fois en IPv4, et en IPv6, il faut que les applications utilisent un format d'adresse sur 128 bits, autrement dit compatible à IPv6.
La version du protocole utilisée dépendra alors de l'adresse de destination.
Lorsque l'adresse de destination est une adresse IPv6 contenant une adresse IPv4, la communication va s'effectuer en utilisant des paquets IPv4.
Et lorsque l'adresse de destination contient bien une adresse IPv6, la communication va s'effectuer par des paquets IPv6.
On voit, que la même application utilise la double pile, et que le choix de la pile est fait en fonction de la version de l'adresse du correspondant.

Soulignons que le développement d'application doit se faire de nos jours exclusivement avec le format d'adresse pour IPv6. Ainsi l’application est compatible avec IPv6, et elle reste toujours utilisable dans un environnement IPv4.

==Problèmes liés au déploiement d'IPv6==

Le déploiement d'IPv6 dans un réseau existant peut amener à des dégradations de service, si des précautions ne sont pas prises. C'est ce que nous allons voir maintenant.

<center>
[[image:V41-5.png|400px|thumb|center|]]
</center>

Le premier problème porte sur la '''phase d'établissement de connexion'''.
Les temps de réponse pour joindre un serveur peut avoir significativement augmenté tout du moins assez pour agacer l'utilisateur. Voyons le problème en détail.

Un client en double pile souhaite accéder à un serveur.
Après interrogation du service de nommage, il obtient les 2 adresses du serveur qui est lui aussi en double pile.
Conformément aux préconisations, le client demande de préférence l'établissement d'une connexion TCP en utilisant IPv6.
IPv6 ayant potentiellement des liens à base de tunnel IPv4, a une connectivité plus fragile. Il se peut que le serveur soit non joignable.
Après plusieurs tentatives infructueuses, qui auront pris de très nombreuses secondes, le client essaye donc avec l'adresse IPv4 et là, la connexion s'établit dans un temps normal.
Devant ce problème, la méthode va consister à tenter la connexion en IPv6 dans un délai très court (de l'ordre de 500 millisecondes), et de passer à IPv4 au plus vite en cas d'échec.

Le second problème est lié à la '''taille des paquets IP'''.
La taille maximale des paquets IPv6 est souvent plus limitée que pour celle pour IPv4, du fait d'un usage des tunnels plus fréquent.
Le client arrive à établir la connexion avec le serveur.
Et tant que les échanges utilisent des petits paquets tout se passe bien.
Dès qu'un paquet de taille supérieure à la taille maximale du paquet permis par le chemin est envoyé. Celui-ci est jeté, du fait qu'un routeur IPv6 ne fait pas de fragmentation.
Le routeur qui supprime le paquet signale à la source, par un message ICMP, cette anomalie de taille.
Mais comme les messages ICMP sont souvent bloqués par des administrateurs réseaux maladroits, il n'y aura pas de fragmentation faite par la source.
Au final, une connexion est établie, mais aucune donnée ne pourra être échangée.
La solution proposée consiste à ce que, TCP surveille la taille des paquets perdus, et que les retransmissions s'effectuent avec des tailles de paquet de plus en plus petites, pour finir par correspondre à la taille maximale du paquet permis par le chemin.

Enfin, un autre problème lié aussi au tunnel, porte sur '''l'interactivité dégradée'''.
Comme la connectivité IPv6 comporte souvent des tunnels.
Les tunnels peuvent être de longueur importante ajoutant des délais au temps de transfert du paquet.
Ainsi, le chemin entre un client et un serveur en IPv6 peut être bien plus long, que si la communication avait été faite en IPv4.
La solution n'est pas au niveau de l'application, elle réside dans la constitution des tunnels. Ceux-ci doivent être les plus courts possible.

==Conclusion==

<center>
[[image:V41-6.png|400px|thumb|center|]]
</center>

La double pile permet la coexistence d'IPv6 avec IPv4 dans le même réseau.
Au commencement, IPv4 reste fonctionnel, et IPv6 ne risque pas de compromettre le bon fonctionnement des services.

Le déploiement d'IPv6 s'effectue progressivement, et constitue bien une extension à IPv4 plutôt qu'un remplacement. Autrement dit, IPv6 est une évolution d'IPv4, et non le moyen de faire un Internet parallèle, et disjoint de l'existant.

Il n'en reste pas moins, que la double pile reste transitoire, et que la présence d'IPv4 oblige à prendre des précautions pour éviter une perte de performance du service fourni par IPv6.

Le service de communication en IPv6 est appelé à s'améliorer avec la disparition progressive d'IPv4.