Livre IPv6 - User contributions [en]

Template:NB-options

2013-08-23T10:17:37Z

Ltoutain:

{|
|+ Valeurs options de Neighbor Discovery
!type !! description !! Message
|-style="background:silver"
|colspan=3|'''Basic Neighbor Discovery options [RFC 4861] '''
|-
|1 || [[Protocole_de_Découverte_des_voisins#Adresse_physique_de_la_source.2Fcible|Source Link-layer Address (SLLAO)]] || RS/RA/NS
|-style="background:silver"
|2 || [[Protocole_de_Découverte_des_voisins#Adresse_physique_de_la_source.2Fcible|Target Link-layer Address ]] || NA/Redirect
|-
|3 || [[Protocole_de_Découverte_des_voisins#Information_sur_le_pr.C3.A9fixe|Prefix Information (PIO)]] || RA
|-style="background:silver"
|4 || [[Protocole_de_Découverte_des_voisins#En-t.C3.AAte_redirig.C3.A9e|Redirected Header]] || Redirect
|-
|5 || [[Protocole_de_Découverte_des_voisins#MTU|MTU]] || RA
|-style="background:silver"
| colspan=3| '''NBMA (unused) [RFC 2491] '''
|-
|6 || NBMA Shortcut Limit Option || NS
|- style="background:silver"
| colspan=3| '''Mobile IP [RFC 3775]'''
|-
|7 || Advertisement Interval Option || RA
|-style="background:silver"
|8 || Home Agent Information Option || RA
|-
|9 || Source Address List ||
|- style="background:silver"
|10 || Target Address List ||
|-
| colspan=3| '''SEND [RFC 3971]'''
|-style="background:silver"
|11 || CGA option ||
|-
|12 || RSA Signature option ||
|-style="background:silver"
|13 || Timestamp option ||
|-
|14 || Nonce option ||
|-style="background:silver"
|15 || Trust Anchor option ||
|-
|16 || Certificate option ||
|-style="background:silver"
| colspan=3| '''Mobility options '''
|-
|17 || IP Address/Prefix Option [RFC 5568] ||
|- style="background:silver"
|18 || New Router Prefix Information Option [RFC 4068] ||
|-
|19 || Link-layer Address Option [RFC 5568] ||
|-style="background:silver"
|20 || Neighbor Advertisement Acknowledgment Option [RFC 5568] ||
|-
|23 || MAP Option [RFC 4140] ||
|- style="background:silver"
| colspan=3| '''SLAAC optimization'''
|-
|24 || Route Information Option [RFC 4191] ||
|-style="background:silver"
|25 || [[Bonnes_pratiques_de_la_configuration_automatique#Alternative_.C3.A0_DHCP|Recursive DNS Server Option]] [RFC 5006] || RA
|-
|26 || RA Flags Extension Option [RFC 5175] ||
|-style="background:silver"
|colspan=3| '''Fast Mobility options '''
|-
|27 || Handover Key Request Option || [RFC 5269]
|-style="background:silver"
|28 || Handover Key Reply Option || [RFC 5269]
|-
|29 || Handover Assist Information Option || [RFC 5271]
|-style="background:silver"
|30 || Mobile Node Identifier Option || [RFC 5271]
|-
|colspan=3| '''6LoWPAN [RFC 6775]'''
|-style="background:silver"
|33 || Address Registration (ARO) ||
|-
| 34 || 6LoWPAN Context (6CO) ||
|-style="background:silver"
| 35 || Authoritative Border Router (ABRO) ||
|-
|157||Duplicate Address Request (DAR) ||
|-style="background:silver"
|158||Duplicate Address Confirmation (DAC)||
|-
|colspan=3|'''Inverse Neighbor Discovery [RFC 3122]'''
|-style="background:silver"
|138 || CARD Request option || [RFC 4065]
|-
|139 || CARD Reply option || [RFC 4065]
|}

Template:NB-options

2013-08-23T10:17:08Z

Ltoutain:

{|
|+ Valeurs options de Neighbor Discovery
!type !! description !! Message
|-style="background:silver"
|colspan=3|'''Basic Neighbor Discovery options [RFC 4861] '''
|-
|1 || [[Protocole_de_Découverte_des_voisins#Adresse_physique_de_la_source.2Fcible|Source Link-layer Address (SLLAO)]] || RS/RA/NS
|-style="background:silver"
|2 || [[Protocole_de_Découverte_des_voisins#Adresse_physique_de_la_source.2Fcible|Target Link-layer Address ]] || NA/Redirect
|-
|3 || [[Protocole_de_Découverte_des_voisins#Information_sur_le_pr.C3.A9fixe|Prefix Information (PIO)]] || RA
|-style="background:silver"
|4 || [[Protocole_de_Découverte_des_voisins#En-t.C3.AAte_redirig.C3.A9e|Redirected Header]] || Redirect
|-
|5 || [[Protocole_de_Découverte_des_voisins#MTU|MTU]] || RA
|-style="background:silver"
| colspan=3| '''NBMA (unused) [RFC 2491] '''
|-
|6 || NBMA Shortcut Limit Option || NS
|- style="background:silver"
| colspan=3| '''Mobile IP [RFC 3775]'''
|-
|7 || Advertisement Interval Option || RA
|-style="background:silver"
|8 || Home Agent Information Option || RA
|-
|9 || Source Address List ||
|- style="background:silver"
|10 || Target Address List ||
|-
| colspan=3| '''SEND [RFC 3971]'''
|-style="background:silver"
|11 || CGA option ||
|-
|12 || RSA Signature option ||
|-style="background:silver"
|13 || Timestamp option ||
|-
|14 || Nonce option ||
|-style="background:silver"
|15 || Trust Anchor option ||
|-
|16 || Certificate option ||
|-style="background:silver"
| colspan=3| '''Mobility options '''
|-
|17 || IP Address/Prefix Option [RFC 5568] ||
|- style="background:silver"
|18 || New Router Prefix Information Option [RFC 4068] ||
|-
|19 || Link-layer Address Option [RFC 5568] ||
|-style="background:silver"
|20 || Neighbor Advertisement Acknowledgment Option [RFC 5568] ||
|-
|23 || MAP Option [RFC 4140] ||
|- style="background:silver"
| colspan=3| '''SLAAC optimization'''
|-
|24 || Route Information Option [RFC 4191] ||
|-style="background:silver"
|25 || [[Bonnes_pratiques_de_la_configuration_automatique#Alternative_.C3.A0_DHCP|Recursive DNS Server Option]] [RFC 5006] || RA
|-
|26 || RA Flags Extension Option [RFC 5175] ||
|-style="background:silver"
|colspan=3| '''Fast Mobility options '''
|-
|27 || Handover Key Request Option || [RFC 5269]
|-style="background:silver"
|28 || Handover Key Reply Option || [RFC 5269]
|-
|29 || Handover Assist Information Option || [RFC 5271]
|-style="background:silver"
|30 || Mobile Node Identifier Option || [RFC 5271]
|-
|colspan=3| '''6LoWPAN [RFC 6775]'''
|-style="background:silver"
|33 || Address Registration (ARO) ||
|-
| 34 || 6LoWPAN Context (6CO) ||
|-style="background:silver"
| 35 || Authoritative Border Router (ABRO) ||
|-
|157||Duplicate Address Request (DAR)
|-style="background:silver"
|158||Duplicate Address Confirmation (DAC)
|-
|colspan=3|'''Inverse Neighbor Discovery [RFC 3122]'''
|-style="background:silver"
|138 || CARD Request option || [RFC 4065]
|-
|139 || CARD Reply option || [RFC 4065]
|}

Template:NB-options

2013-08-23T10:14:33Z

Ltoutain:

{|
|+ Valeurs options de Neighbor Discovery
!type !! description !! Message
|-style="background:silver"
|colspan=3|'''Basic Neighbor Discovery options [RFC 4861] '''
|-
|1 || [[Protocole_de_Découverte_des_voisins#Adresse_physique_de_la_source.2Fcible|Source Link-layer Address (SLLAO)]] || RS/RA/NS
|-style="background:silver"
|2 || [[Protocole_de_Découverte_des_voisins#Adresse_physique_de_la_source.2Fcible|Target Link-layer Address ]] || NA/Redirect
|-
|3 || [[Protocole_de_Découverte_des_voisins#Information_sur_le_pr.C3.A9fixe|Prefix Information (PIO)]] || RA
|-style="background:silver"
|4 || [[Protocole_de_Découverte_des_voisins#En-t.C3.AAte_redirig.C3.A9e|Redirected Header]] || Redirect
|-
|5 || [[Protocole_de_Découverte_des_voisins#MTU|MTU]] || RA
|-style="background:silver"
| colspan=3| '''NBMA (unused) [RFC 2491] '''
|-
|6 || NBMA Shortcut Limit Option || NS
|- style="background:silver"
| colspan=3| '''Mobile IP [RFC 3775]'''
|-
|7 || Advertisement Interval Option || RA
|-style="background:silver"
|8 || Home Agent Information Option || RA
|-
|9 || Source Address List ||
|- style="background:silver"
|10 || Target Address List ||
|-
| colspan=3| '''SEND [RFC 3971]'''
|-style="background:silver"
|11 || CGA option ||
|-
|12 || RSA Signature option ||
|-style="background:silver"
|13 || Timestamp option ||
|-
|14 || Nonce option ||
|-style="background:silver"
|15 || Trust Anchor option ||
|-
|16 || Certificate option ||
|-style="background:silver"
| colspan=3| '''Mobility options '''
|-
|17 || IP Address/Prefix Option [RFC 5568] ||
|- style="background:silver"
|18 || New Router Prefix Information Option [RFC 4068] ||
|-
|19 || Link-layer Address Option [RFC 5568] ||
|-style="background:silver"
|20 || Neighbor Advertisement Acknowledgment Option [RFC 5568] ||
|-
|23 || MAP Option [RFC 4140] ||
|- style="background:silver"
| colspan=3| '''SLAAC optimization'''
|-
|24 || Route Information Option [RFC 4191] ||
|-style="background:silver"
|25 || [[Bonnes_pratiques_de_la_configuration_automatique#Alternative_.C3.A0_DHCP|Recursive DNS Server Option]] [RFC 5006] || RA
|-
|26 || RA Flags Extension Option [RFC 5175] ||
|-style="background:silver"
|colspan=3| '''Fast Mobility options '''
|-
|27 || Handover Key Request Option || [RFC 5269]
|-style="background:silver"
|28 || Handover Key Reply Option || [RFC 5269]
|-
|29 || Handover Assist Information Option || [RFC 5271]
|-style="background:silver"
|30 || Mobile Node Identifier Option || [RFC 5271]
|-
|colspan=3| '''6LoWPAN '''
|-style="background:silver"
|33 || Address Registration (ARO) || [RFC 6775]
|-
| 34 || 6LoWPAN Context (6CO) || [RFC 6775]
|-style="background:silver"
| 35 || Authoritative Border Router (ABRO) || [RFC 6775]
|-
|colspan=3|'''Inverse Neighbor Discovery [RFC 3122]'''
|-style="background:silver"
|138 || CARD Request option || [RFC 4065]
|-
|139 || CARD Reply option || [RFC 4065]
|}

Template:NB-options

2013-08-23T10:13:43Z

Ltoutain:

{|
|+ Valeurs options de Neighbor Discovery
!type !! description !! Message
|-style="background:silver"
|colspan=3|'''Basic Neighbor Discovery options [RFC 4861] '''
|-
|1 || [[Protocole_de_Découverte_des_voisins#Adresse_physique_de_la_source.2Fcible|Source Link-layer Address (SLLAO)]] || RS/RA/NS
|-style="background:silver"
|2 || [[Protocole_de_Découverte_des_voisins#Adresse_physique_de_la_source.2Fcible|Target Link-layer Address ]] || NA/Redirect
|-
|3 || [[Protocole_de_Découverte_des_voisins#Information_sur_le_pr.C3.A9fixe|Prefix Information (PIO)]] || RA
|-style="background:silver"
|4 || [[Protocole_de_Découverte_des_voisins#En-t.C3.AAte_redirig.C3.A9e|Redirected Header]] || Redirect
|-
|5 || [[Protocole_de_Découverte_des_voisins#MTU|MTU]] || RA
|-style="background:silver"
| colspan=3| '''NBMA (unused) [RFC 2491] '''
|-
|6 || NBMA Shortcut Limit Option || NS
|- style="background:silver"
| colspan=3| '''Mobile IP [RFC 3775]'''
|-
|7 || Advertisement Interval Option || RA
|-style="background:silver"
|8 || Home Agent Information Option || RA
|-
|9 || Source Address List ||
|- style="background:silver"
|10 || Target Address List ||
|-
| colspan=3| '''SEND [RFC 3971]'''
|-style="background:silver"
|11 || CGA option ||
|-
|12 || RSA Signature option ||
|-style="background:silver"
|13 || Timestamp option ||
|-
|14 || Nonce option ||
|-style="background:silver"
|15 || Trust Anchor option ||
|-
|16 || Certificate option ||
|-style="background:silver"
| colspan=3| '''Mobility options '''
|-
|17 || IP Address/Prefix Option [RFC 5568] ||
|- style="background:silver"
|18 || New Router Prefix Information Option [RFC 4068] ||
|-
|19 || Link-layer Address Option [RFC 5568] ||
|-style="background:silver"
|20 || Neighbor Advertisement Acknowledgment Option [RFC 5568] ||
|-
|23 || MAP Option [RFC 4140] ||
|- style="background:silver"
| colspan=3| '''SLAAC optimization'''
|-
|24 || Route Information Option [RFC 4191] ||
|-style="background:silver"
|25 || [[Bonnes_pratiques_de_la_configuration_automatique#Alternative_.C3.A0_DHCP|Recursive DNS Server Option]] [RFC 5006] || RA
|-
|26 || RA Flags Extension Option [RFC 5175] ||
|-style="background:silver"
|colspan=3| '''Fast Mobility options '''
|-
|27 || Handover Key Request Option || [RFC 5269]
|-style="background:silver"
|28 || Handover Key Reply Option || [RFC 5269]
|-
|29 || Handover Assist Information Option || [RFC 5271]
|-style="background:silver"
|30 || Mobile Node Identifier Option || [RFC 5271]
|-
|colspan=3| '''6LoWPAN '''
|-
|33 || Address Registration (ARO) || [RFC 6775]
|-style="background:silver"
| 34 || 6LoWPAN Context (6CO) || [RFC 6775]
|-
| 35 || Authoritative Border Router (ABRO) || [RFC 6775]
|-style="background:silver"
|colspan=3|'''Inverse Neighbor Discovery [RFC 3122]'''
|-
|138 || CARD Request option || [RFC 4065]
|-style="background:silver"
|139 || CARD Reply option || [RFC 4065]
|}

Template:NB-options

2013-08-23T10:12:12Z

Ltoutain:

{|
|+ Valeurs options de Neighbor Discovery
!type !! description !! Message
|-style="background:silver"
|colspan=3|'''Basic Neighbor Discovery options [RFC 4861] '''
|-
|1 || [[Protocole_de_Découverte_des_voisins#Adresse_physique_de_la_source.2Fcible|Source Link-layer Address (SLLAO)]] || RS/RA/NS
|-style="background:silver"
|2 || [[Protocole_de_Découverte_des_voisins#Adresse_physique_de_la_source.2Fcible|Target Link-layer Address ]] || NA/Redirect
|-
|3 || [[Protocole_de_Découverte_des_voisins#Information_sur_le_pr.C3.A9fixe|Prefix Information (PIO)]] || RA
|-style="background:silver"
|4 || [[Protocole_de_Découverte_des_voisins#En-t.C3.AAte_redirig.C3.A9e|Redirected Header]] || Redirect
|-
|5 || [[Protocole_de_Découverte_des_voisins#MTU|MTU]] || RA
|-style="background:silver"
| colspan=3| '''NBMA (unused) [RFC 2491] '''
|-
|6 || NBMA Shortcut Limit Option || NS
|- style="background:silver"
| colspan=3| '''Mobile IP [RFC 3775]'''
|-
|7 || Advertisement Interval Option || RA
|-style="background:silver"
|8 || Home Agent Information Option || RA
|-
|9 || Source Address List ||
|- style="background:silver"
|10 || Target Address List ||
|-
| colspan=3| '''SEND [RFC 3971]'''
|-style="background:silver"
|11 || CGA option ||
|-
|12 || RSA Signature option ||
|-style="background:silver"
|13 || Timestamp option ||
|-
|14 || Nonce option ||
|-style="background:silver"
|15 || Trust Anchor option ||
|-
|16 || Certificate option ||
|-style="background:silver"
| colspan=3| '''Mobility options '''
|-
|17 || IP Address/Prefix Option [RFC 5568] ||
|- style="background:silver"
|18 || New Router Prefix Information Option [RFC 4068] ||
|-
|19 || Link-layer Address Option [RFC 5568] ||
|-style="background:silver"
|20 || Neighbor Advertisement Acknowledgment Option [RFC 5568] ||
|-
|23 || MAP Option [RFC 4140] ||
|- style="background:silver"
| colspan=3| '''SLAAC optimization'''
|-
|24 || Route Information Option [RFC 4191] ||
|-style="background:silver"
|25 || [[Bonnes_pratiques_de_la_configuration_automatique#Alternative_.C3.A0_DHCP|Recursive DNS Server Option]] [RFC 5006] || RA
|-
|26 || RA Flags Extension Option [RFC 5175] ||
|-style="background:silver"
|colspan=3| '''Fast Mobility options '''
|-
|27 || Handover Key Request Option || [RFC 5269]
|-style="background:silver"
|28 || Handover Key Reply Option || [RFC 5269]
|-
|29 || Handover Assist Information Option || [RFC 5271]
|-style="background:silver"
|30 || Mobile Node Identifier Option || [RFC 5271]
|-
|33 || Address Registration (ARO) || [RFC 6775]
|-style="background:silver"
| 34 || 6LoWPAN Context (6CO) || [RFC 6775]
|-
| 35 || Authoritative Border Router (ABRO) || [RFC 6775]
|-style="background:silver"
|colspan=3|'''Inverse Neighbor Discovery [RFC 3122]'''
|-
|138 || CARD Request option || [RFC 4065]
|-style="background:silver"
|139 || CARD Reply option || [RFC 4065]
|}

Template:NB-options

2013-08-23T10:11:24Z

Ltoutain:

{|
|+ Valeurs options de Neighbor Discovery
!type !! description !! Message
|-style="background:silver"
|colspan=3|'''Basic Neighbor Discovery options [RFC 4861] '''
|-
|1 || [[Protocole_de_Découverte_des_voisins#Adresse_physique_de_la_source.2Fcible|Source Link-layer Address (SLLAO)]] || RS/RA/NS
|-style="background:silver"
|2 || [[Protocole_de_Découverte_des_voisins#Adresse_physique_de_la_source.2Fcible|Target Link-layer Address ]] || NA/Redirect
|-
|3 || [[Protocole_de_Découverte_des_voisins#Information_sur_le_pr.C3.A9fixe|Prefix Information (PIO)]] || RA
|-style="background:silver"
|4 || [[Protocole_de_Découverte_des_voisins#En-t.C3.AAte_redirig.C3.A9e|Redirected Header]] || Redirect
|-
|5 || [[Protocole_de_Découverte_des_voisins#MTU|MTU]] || RA
|-style="background:silver"
| colspan=3| '''NBMA (unused) [RFC 2491] '''
|-
|6 || NBMA Shortcut Limit Option || NS
|- style="background:silver"
| colspan=3| '''Mobile IP [RFC 3775]'''
|-
|7 || Advertisement Interval Option || RA
|-style="background:silver"
|8 || Home Agent Information Option || RA
|-
|33 || Address Registration (ARO) || [RFC 6775]
|-style="background:silver"
| 34 || 6LoWPAN Context (6CO) || [RFC 6775]
|-
| 35 || Authoritative Border Router (ABRO) || [RFC 6775]
|-style="background:silver"
|colspan=3|'''Inverse Neighbor Discovery [RFC 3122]'''
|-
|9 || Source Address List ||
|- style="background:silver"
|10 || Target Address List ||
|-
| colspan=3| '''SEND [RFC 3971]'''
|-style="background:silver"
|11 || CGA option ||
|-
|12 || RSA Signature option ||
|-style="background:silver"
|13 || Timestamp option ||
|-
|14 || Nonce option ||
|-style="background:silver"
|15 || Trust Anchor option ||
|-
|16 || Certificate option ||
|-style="background:silver"
| colspan=3| '''Mobility options '''
|-
|17 || IP Address/Prefix Option [RFC 5568] ||
|- style="background:silver"
|18 || New Router Prefix Information Option [RFC 4068] ||
|-
|19 || Link-layer Address Option [RFC 5568] ||
|-style="background:silver"
|20 || Neighbor Advertisement Acknowledgment Option [RFC 5568] ||
|-
|23 || MAP Option [RFC 4140] ||
|- style="background:silver"
| colspan=3| '''SLAAC optimization'''
|-
|24 || Route Information Option [RFC 4191] ||
|-style="background:silver"
|25 || [[Bonnes_pratiques_de_la_configuration_automatique#Alternative_.C3.A0_DHCP|Recursive DNS Server Option]] [RFC 5006] || RA
|-
|26 || RA Flags Extension Option [RFC 5175] ||
|-style="background:silver"
|colspan=3| '''Fast Mobility options '''
|-
|27 || Handover Key Request Option || [RFC 5269]
|-style="background:silver"
|28 || Handover Key Reply Option || [RFC 5269]
|-
|29 || Handover Assist Information Option || [RFC 5271]
|-style="background:silver"
|30 || Mobile Node Identifier Option || [RFC 5271]
|-
|138 || CARD Request option || [RFC 4065]
|-style="background:silver"
|139 || CARD Reply option || [RFC 4065]
|}

Main Page

2012-09-05T17:23:08Z

Ltoutain: /* IPv6 Théorie et Pratique */

=<center>'''IPv6 Théorie et Pratique'''</center>=
<center>''G6 Formation''</center>

Bonjour,

Les évolutions autour du protocole IPv6 sont de plus en plus rapides. C'est
bon signe pour la vitalité du protocole, mais il est de plus en plus difficile
que la version papier du livre IPv6 théorie et pratique (ISBN 284177337X) soit toujours à jour. $latex \epsilon$

Aussi le [http://www.g6.asso.fr G6] a décidé
d'en faire une version en ligne (accessible en IPv4 et IPv6). Ce serveur reprend la quatrième édition du livre IPv6 théorie et Pratique paru en Novembre
2005 chez O'Reilly (actuellement épuisé). Le but de ce site est de le faire évoluer le texte pour suivre
au plus près les évolutions d'IPv6, d'établir un dialogue avec les lecteurs répondre
plus clairement aux demandes des utilisateurs. D'un point de vue pratique, il permettra
également aux auteurs de mieux collaborer pour maintenir à jour les informations.

Vous pouvez commencer votre lecture par la [[Table des matières|table des matières]] ou le [[Préambule|préambule]]

L'intégralité du texte est maintenant en ligne, nous allons maintenant rendre les figures plus lisibles. Cela
demande un peu plus de temps car il faut remonter aux sources des contributions des différents auteurs.

Bonne Lecture

G6 Formation

PS: un [http://www.g6.asso.fr/blog blog] est également à votre disposition pour commenter
l'actualité, les avantages ou les problèmes techniques liés à l'arrivée d'IPv6.

PPS: Le [http://c2.touta.in/?p=222 lien suivant] permet de voir une partie du cours IPv6 donné à Télécom Bretagne.



<keywords content="IPv6,G6,livre,référence,book">

TdMbis

2012-08-29T12:52:14Z

Ltoutain: /* Sécurité (Pierre Françon ?) */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

Recherche

Résoudre le problème du MH

* LISP
* Shim6/SCTP/MPTCP
* HIP

-----
Bruno: VRRP,

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (TBD) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= [[IntegrationBis|Intégration d'IPv6 et des applications (Bruno Stévant)]] =

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2012-08-29T12:38:58Z

Ltoutain: /* Routage (Alain Bidaud) */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

Recherche

Résoudre le problème du MH

* LISP
* Shim6/SCTP/MPTCP
* HIP

-----
Bruno: VRRP,

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= [[IntegrationBis|Intégration d'IPv6 et des applications (Bruno Stévant)]] =

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

Main Page

2012-02-23T18:51:01Z

Ltoutain: /* IPv6 Théorie et Pratique */

=<center>'''IPv6 Théorie et Pratique'''</center>=
<center>''G6 Formation''</center>

Bonjour,

Les évolutions autour du protocole IPv6 sont de plus en plus rapides. C'est
bon signe pour la vitalité du protocole, mais il est de plus en plus difficile
que la version papier du livre IPv6 théorie et pratique (ISBN 284177337X) soit toujours à jour.

Aussi le [http://www.g6.asso.fr G6] a décidé
d'en faire une version en ligne (accessible en IPv4 et IPv6). Ce serveur reprend la quatrième édition du livre IPv6 théorie et Pratique paru en Novembre
2005 chez O'Reilly (actuellement épuisé). Le but de ce site est de le faire évoluer le texte pour suivre
au plus près les évolutions d'IPv6, d'établir un dialogue avec les lecteurs répondre
plus clairement aux demandes des utilisateurs. D'un point de vue pratique, il permettra
également aux auteurs de mieux collaborer pour maintenir à jour les informations.

Vous pouvez commencer votre lecture par la [[Table des matières|table des matières]] ou le [[Préambule|préambule]]

L'intégralité du texte est maintenant en ligne, nous allons maintenant rendre les figures plus lisibles. Cela
demande un peu plus de temps car il faut remonter aux sources des contributions des différents auteurs.

Bonne Lecture

G6 Formation

PS: un [http://www.g6.asso.fr/blog blog] est également à votre disposition pour commenter
l'actualité, les avantages ou les problèmes techniques liés à l'arrivée d'IPv6.

PPS: Le [http://c2.touta.in/?p=222 lien suivant] permet de voir une partie du cours IPv6 donné à Télécom Bretagne.



<keywords content="IPv6,G6,livre,référence,book">

Main Page

2012-02-23T18:49:50Z

Ltoutain: /* IPv6 Théorie et Pratique */

=<center>'''IPv6 Théorie et Pratique'''</center>=
<center>''G6 Formation''</center>

Bonjour,

Les évolutions autour du protocole IPv6 sont de plus en plus rapides. C'est
bon signe pour la vitalité du protocole, mais il est de plus en plus difficile
que la version papier du livre IPv6 théorie et pratique (ISBN 284177337X) soit toujours à jour.

Aussi le [http://www.g6.asso.fr G6] a décidé
d'en faire une version en ligne (accessible en IPv4 et IPv6). Ce serveur reprend la quatrième édition du livre IPv6 théorie et Pratique paru en Novembre
2005 chez O'Reilly (actuellement épuisé). Le but de ce site est de le faire évoluer le texte pour suivre
au plus près les évolutions d'IPv6, d'établir un dialogue avec les lecteurs répondre
plus clairement aux demandes des utilisateurs. D'un point de vue pratique, il permettra
également aux auteurs de mieux collaborer pour maintenir à jour les informations.

Vous pouvez commencer votre lecture par la [[Table des matières|table des matières]] ou le [[Préambule|préambule]]

L'intégralité du texte est maintenant en ligne, nous allons maintenant rendre les figures plus lisibles. Cela
demande un peu plus de temps car il faut remonter aux sources des contributions des différents auteurs.

Bonne Lecture

G6 Formation

PS: un [http://www.g6.asso.fr/blog blog] est également à votre disposition pour commenter
l'actualité, les avantages ou les problèmes techniques liés à l'arrivée d'IPv6.

PPS: Le [http://c2.touta.in/?p=222 lien suivant] permet de voir une partie du cours IPv6 donné à Télécom Bretagne.

[[Español]]



<keywords content="IPv6,G6,livre,référence,book">

Main Page

2012-02-23T18:49:29Z

Ltoutain: /* IPv6 Théorie et Pratique */

=<center>'''IPv6 Théorie et Pratique'''</center>=
<center>''G6 Formation''</center>

Bonjour,

Les évolutions autour du protocole IPv6 sont de plus en plus rapides. C'est
bon signe pour la vitalité du protocole, mais il est de plus en plus difficile
que la version papier du livre IPv6 théorie et pratique (ISBN 284177337X) soit toujours à jour.

Aussi le [http://www.g6.asso.fr G6] a décidé
d'en faire une version en ligne (accessible en IPv4 et IPv6). Ce serveur reprend la quatrième édition du livre IPv6 théorie et Pratique paru en Novembre
2005 chez O'Reilly (actuellement épuisé). Le but de ce site est de le faire évoluer le texte pour suivre
au plus près les évolutions d'IPv6, d'établir un dialogue avec les lecteurs répondre
plus clairement aux demandes des utilisateurs. D'un point de vue pratique, il permettra
également aux auteurs de mieux collaborer pour maintenir à jour les informations.

Vous pouvez commencer votre lecture par la [[Table des matières|table des matières]] ou le [[Préambule|préambule]]

L'intégralité du texte est maintenant en ligne, nous allons maintenant rendre les figures plus lisibles. Cela
demande un peu plus de temps car il faut remonter aux sources des contributions des différents auteurs.

Bonne Lecture

G6 Formation

PS: un [http://www.g6.asso.fr/blog blog] est également à votre disposition pour commenter
l'actualité, les avantages ou les problèmes techniques liés à l'arrivée d'IPv6.

PPS: Le [http://c2.touta.in/?p=222 lien suivant] permet de voir une partie du cours IPv6 donné à Télécom Bretagne.



<keywords content="IPv6,G6,livre,référence,book">

[[Español]]

AdressageBis-Fondamentaux

2011-12-25T21:11:29Z

Ltoutain: /* Adressage Multicast Sollicité */

{{Suivi| Introduction|Introduction | AdressageBis-MeO|Mises en Oeuvre}}

Le format et la représentation des adresses sont les modifications les plus visibles pour l'utilisateur expérimenté et l'ingénieur réseau dans cette nouvelle version du protocole. En effet la taille de l'adresse reste fixe mais passe de 32 à 128 bits. Même si les principes sont fortement similaires à ceux employés dans IPv4, cet adressage apparaît à première vue beaucoup plus complexe. Il est intéressant d'en comprendre le principe et les règles d'attribution avant d'aborder les aspects protocolaires.

Ce chapitre présente les différents types d'adresses. Il explique en détail le plan d'adressage agrégé qui a été retenu pour construire l'Internet IPv6. Il décrit également la manière de constituer une adresse IPv6.

= Aspects fondamentaux de l'adressage IPv6=

==<div id="representation">Représentation des adresses ==

La représentation textuelle d'une adresse IPv6 se fait en découpant le mot de 128 bits de l'adresse en 8 mots de 16 bits séparés par le caractère «:», chacun d'eux étant représenté en hexadécimal. Par exemple :

<tt>2001:0DB8:0000:0000:0400:A987:6543:210F</tt>

Dans un champ, il n'est pas nécessaire d'écrire les zéros placés en tête :

<tt>2001:DB8:0:0:400:A987:6543:210F</tt>

En outre plusieurs champs nuls consécutifs peuvent être abrégés par «::». Ainsi l'adresse précédente peut s'écrire comme suit :

<tt>2001:DB8::400:A987:6543:210F</tt>

Naturellement, pour éviter toute ambiguïté, l'abréviation «::» ne peut apparaître qu'une fois au plus dans une adresse. Les cas extrêmes sont l'adresse indéfinie (utilisée pour désigner les routes par défaut) à tous les bits à zéro et qui se note de manière compacte :

<tt>::</tt>

et l'adresse de bouclage (loopback), équivalent du préfixe <tt>127/8</tt> dont tous les bits sont à zéro sauf le dernier et qui s'écrit :

<tt>::1</tt>

La représentation des préfixes réseau IPv6 est similaire à la notation CIDR RFC 1519 utilisée pour les préfixes IPv4. Un préfixe IPv6 est donc représenté par la notation :

adresse-ipv6/longueur-du-préfixe-en-bits

Les formes abrégées avec «::» sont autorisées.

<tt>2001:0DB8:7654:3210:0000:0000:0000:0000/64
2001:DB8:7654:3210:0:0:0:0/64
2001:DB8:7654:3210::/64</tt>

Le seul piège de cette notation vient des longueurs de préfixes qui ne sont pas en frontière de «:». Ainsi le préfixe <tt>3EDC:BA98:7654:3::/56</tt> équivaut en réalité à <tt>3EDC:BA98:7654:0000::/56</tt> car il s'écrit <tt>3EDC:BA98:7654:0003::/56</tt>.

On peut combiner le préfixe réseau avec l'identifiant de l'interface en une seule notation. Ainsi cette adresse IPV6
<tt>2001:DB8:7654:3210:945:1321:ABA8:F4E2/64</tt>
indique que le préfixe réseau est constitué par les 64 premiers bits.

{{HorsTexte|Apprendre à gaspiller|Du fait de sa longueur, une règle de bonne gestion consiste à relâcher les contraintes sur les longueurs de préfixe. Ainsi en utilisant quand cela est possible des multiples de 4 permet d'avoir un préfixe qui tient sur un caractère affiché. Dans l'exemple suivant 47 n'étant pas un multiple de 4, <tt>2001:DB0:1234::/47</tt> représente les préfixes commençant par <tt>2001:DB0:1234</tt> et <tt>2001:DB0:1235</tt>}}

Ces représentations peuvent apparaître beaucoup plus complexes qu'avec IPv4, mais en vérité des adresses logiques ou concises peuvent être constituées au moyen de règles strictes. Ces règles favorisent grandement la manipulation et la mémorisation des adresses comme nous verrons par la suite (cf Adressage global)

Dans certains cas, une adresse (voire plusieurs adresses) IPv4 peut être contenue dans une adresse IPv6. Pour les faire ressortir, la notation classique d'IPv4, c'est à dire 4 octets en représentation décimale séparés par des points, peut être utilisée au sein d'une adresse IPv6. Ainsi :

<tt>::128.12.13.14</tt>

représente une adresse IPv6 composée de 96 bits à 0 suivis des 32 bits de l'adresse IPv4 <tt>128.12.13.14</tt>

Il est pourtant parfois nécessaire de manipuler littéralement des adresses IPv6. Le caractère ":" utilisé pour séparer les mots peut créer des ambiguïtés. C'est le cas avec les URL où il est aussi utilisé pour indiquer le numéro de port. Ainsi l'URL

<tt><nowiki>http://2001:DB8:12::1:8000/</nowiki></tt>

peut aussi bien indiquer le port 8000 sur la machine ayant l'adresse IPv6 2001:DB8:12::1, que la machine 2001:DB8:12::1:8000 en utilisant le port par défaut. Pour lever cette ambiguïté, le RFC 2732 propose d'inclure l'adresse IPv6 entre "[ ]". L'adresse précédente s'écrirait :

<tt><nowiki>http://[2001:DB8:12::1]:8000/</nowiki></tt>

ou

<tt><nowiki>http://[2001:DB8:12::1:8000]/</nowiki></tt>

suivant les cas. Cette représentation peut être étendue à d'autres domaines comme X-window ou au protocole de signalisation téléphonique SIP.

== Type des adresses ==

IPv6 reconnaît trois types d'adresses : unicast, multicast et anycast. Le type d'adresse définit la cardinalité de la communication: à combien de destinataire doit être remis le paquet.

Le premier de ces types désigne de manière unique une interface. Un paquet envoyé à une telle adresse, sera donc remis à l'interface ainsi identifiée. Parmi les adresses unicast, on peut distinguer celles qui auront une portée globale, c'est-à-dire désignant sans ambiguïté une destination sur le réseau Internet et celles qui auront une portée locale (lien ou site). Ces dernières ne pourront pas être routées sur l'Internet c'est à dire qu'un paquet comportant une adresse de destination avec une portée locale sera ignoré et éliminé par un routeur de l'Internet. La portée d'une adresse indique en faite la limite de la propriété d'unicité.

Une adresse de type multicast désigne un groupe d'interfaces qui en général appartiennent à des noeuds différents pouvant être situés n'importe où dans l'Internet. Lorsqu'un paquet a pour destination une adresse de type multicast, il est acheminé par le réseau à toutes les interfaces membres de ce groupe.

Il faut noter qu'il n'y a plus d'adresses de type broadcast comme sous IPv4 ; elles sont remplacées par des adresses de type multicast. En effet, l'adresse de broadcast peut être émulée avec une adresse multicast en constituant un groupe qui comporte tous les noeuds. De plus, l'absence de broadcast évite les problèmes de saturation des réseaux locaux commutés. Ainsi un réseau IPV6 passe mieux en terme de facteur d'échelle sur ce type de réseau.

Le dernier type, anycast, est une officialisation de propositions faites pour IPv4 RFC 1546. Comme dans le cas du multicast, une adresse de type anycast désigne un groupe d'interfaces, la différence étant que lorsqu'un paquet a pour destination une telle adresse, il est acheminé à un des éléments du groupe et non pas à tous. C'est, par exemple, le plus proche au sens de la métrique des protocoles de routage. Cet adressage est principalement expérimental, voir [[Anycast|Adresses anycast]].

Certains types d'adresses sont caractérisés par leur préfixe RFC 3513. Le tableau suivant (source : http://www.iana.org/assignments/ipv6-address-space) donne la liste de ces préfixes. La plage «réservée» du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70% de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.

{|
!Préfixe IPv6!!Allouer!!Référence
|-style="background:silver"
|<tt>0000::/8</tt>||[[Autres types d'adresses|Réservé pour la transition et loopback]]||RFC 3513
|-
|<tt>0100::/8</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>0200::/7</tt>||Réservé (ex [[Autres types d'adresses#Les adresses NSAP|NSAP]])||RFC 4048
|-
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 3513
|-style="background:silver"
|<tt>0800::/5</tt>||Réservé||RFC 3513
|-
|<tt>1000::/4</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>2000::/3</tt>||[[Unicast Global]]||RFC 3513
|-
|<tt>4000::/3</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>6000::/3</tt>||Réservé||RFC 3513
|-
|<tt>8000::/3</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>A000::/3</tt>||Réservé||RFC 3513
|-
|<tt>C000::/3</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>E000::/4</tt>||Réservé||RFC 3513
|-
|<tt>F000::/5</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>F800::/6</tt>||Réservé||RFC 3513
|-
|<tt>FC00::/7</tt>||[[Site-local#ula|Unique Local Unicast]]||RFC 4193
|-style="background:silver"
|<tt>FE00::/9</tt> ||Réservé||RFC 3513
|-
|<tt>FE80::/10</tt>||[[Lien-local]]||RFC 3513
|-style="background:silver"
|<tt>FEC0::/10</tt>||Réservé||RFC 3879
|-
|<tt>FF00::/8</tt>||Multicast||RFC 3513
|}

Une interface possèdera généralement plusieurs adresses IPv6. En IPv4 ce comportement est exceptionnel, il est banalisé en IPv6.

= Adressage global : plan d'adressage agrégé =

Ce plan, proposée dans le RFC 3587, précise la structure d'adressage IPv6 définie dans le RFC 3513 en précisant les tailles de chacun des blocs. Il est géré de la même manière que CIDR en IPv4. Une adresse intègre trois niveaux de hiérarchie :

<tikz title="Adresses Globales">
\clip (0.0, 0) rectangle (11.5,7);
% \draw[help lines] (0,0) grid (10,6);

% \draw (0, 6.6) node [right] {Global Unicast Address:};

\draw (0,5) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tt{001}};
\draw (1,5) node [right, draw, shade, top color = green, minimum width=3cm, minimum height=1cm] {Global Prefix};
\draw (4,5) node [right, draw, shade, top color = blue, minimum width=1.5cm, minimum height=1cm] {SID};
\draw (5.5,5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.5, 5.7) node {\tiny{3}};
\draw (2.5, 5.7) node {\tiny{45}};
\draw (4.7, 5.7) node {\tiny{16}};
\draw (8, 5.7) node {\tiny{64}};

\draw [snake=brace, mirror snake] (0, 4.20) -- (4, 4.20) node [below, midway] {\tiny{
\ifthenelse{\equal{francais}{true}}{Topologie Publique}{public topology}}
} node [below = 8pt, midway] {\tiny{given by the provider}} ;
\draw [snake=brace, mirror snake] (4, 4.20) -- (5.5, 4.20) node [below, midway] {\tiny{local topology}} node [below = 8pt, midway] {\tiny{assigned by network engineer}} ;
\draw [snake=brace, mirror snake] (5.5, 4.20) -- (10.3, 4.20) node [below, midway] {\tiny{link address}} node [below = 8pt, midway] {\tiny{auto or manual configuration}} ;
</tikz>

* une topologie publique (appelée '''Global Prefix''') codée sur 48 bits, allouée par le fournisseur d'accès;
* une topologie de site codée sur 16 bits (appelée '''Subnet ID'''). Ce champ permet de coder les numéros de sous réseau du site;
* un [[identifiant d'interface]] sur 64 bits (appelé '''Interface ID''') distinguant les différentes machines sur le lien.

==Structuration du prefixe global (GP)==

{{HorsTexte|Appréhender les tailles|France Télécom a obtenu du RIPE-NCC un <tt>/19</tt>. Si l'on enlève les troix premiers bits <tt>001</tt> désignant le plan d'adressage, il est donc possible d'avoir 216 opérateurs. Sachant qu'il y a 192 pays à l'ONU, ils pourraient chacun abriter 320 opérateurs de la taille de FT, chacun pouvant attribuer jusqu'à 229 <tt>/48</tt>, soit 536 870 912 sites}}

A part le préfixe <tt>2002::</tt> qui est est réservé au mécanisme de transition [[6to4]], cet espace est géré hierarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales ([http://www.iana.org/numbers/ RIR]) des préfixes actuellement de longueur 12 (cf. http://www.iana.org/assignments/ipv6-unicast-address-assignments) qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long. Le site http://www.sixxs.net/tools/grh/ donne en temps réel les allocations de préfixes par région, opérateur et pays.

Il est maintenant admis que le préfixe attribué par un opérateur à ses clients peut également être un <tt>/56</tt>. En effet, si l'on garde l'attribution de préfixe de longueur 48 pour les sites terminaux, et que l'on intègre les réseaux domotiques, les opérateurs peuvent justifier d'un besoin important d'adresses que les autorités régionales ne peuvent leur refuser.

{{ToDo|Ajouter comment obtenir un préfixe auprès de RIPE-NCC}}

==Structuration de l'identifiant de sous-réseau (SID)==

Il n'existe pas de règles pour allouer les identificateurs de sous-réseau au sein d'un site. Plusieurs techniques (non exclusives) peuvent être utilisées :

* numéroter de manière incrémentale les sous-réseaux: 0001, 0002, ... Cette technique est simple a mettre en œuvre dans des réseaux expérimentaux, mais elle peut conduire à un plan d'adressage à plat difficile à mémoriser. Elle peut être utilisée par exemple pour un sous-réseau dédié aux serveurs pour simplifier l'écriture et la mémorisation des adresses.
* utiliser le numéro de VLAN. Elle permet d'éviter de mémoriser plusieurs niveaux de numérotation.
* séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau suivant contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs :

{|
!Communauté !! 4bits !! width="50%"|8bits !! 4bits
|-style="background:silver"
| Infrastructure || 0 || colspan=2 | valeurs spécifiques
|-
| Tests || 1 || colspan=2 | valeurs spécifiques
|-style="background:silver"
| Tunnels || 6 || colspan=2 | allocation de /60 aux utilisateurs
|-
| Invités Wi-Fi || 8 || colspan=2 | valeurs spécifiques
|-style="background:silver"
| Personnels || A || Entité || Sous-Réseaux
|-
| Etudiants || E || Entité || Sous-Réseaux
|-style="background:silver"
| Autres (Start up, etc.) || F || colspan=2 | valeurs spécifiques
|+ Affectation des SID dans une université
|}

Ainsi, le préfixe:
* <tt>2001:DB8:1234::/52</tt> servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs seront prises dans cet espace;
* <tt>2001:DB8:1234:8000::/52</tt> servira pour le réseau Wi-Fi des invités. La manière dont sont gérés les 12 bits restants du SID ne sont pas spécifiés;
* <tt>2001:DB8:1234:E000::/52</tt> servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.

=== Adressage local : adresses lien-local ===

Les adresses de type lien-local (''link local use address'') sont des adresses dont la validité est restreinte à un lien, c'est-à-dire l'ensemble de interfaces directement connectées sans routeur intermédiaire comme par exemple des machines branchées sur un même réseau Ethernet, des machines reliées par une connexion PPP, ou des extrémités d'un tunnel. Les adresses lien-local sont configurées automatiquement à l'initialisation de l'interface et permettent la communication entre nœuds voisins. L'adresse est obtenue en concaténant le préfixe <tt>FE80::/64</tt> aux 64 bits de l'[[Identifiant d'interface|identifiant d'interface]]. L'identifiant d'interface est généralement basé sur l'adresse MAC. Cela ne pose pas de problème de respect de le vie privée car, contrairement aux adresses globales, les adresses lien-local ne sortent jamais du réseau où elles sont utilisées.

<tikz title="Adresses Lien-local">
% \draw (0, 3) node [right] {Link-Local Address:};
\draw (0,1.5) node [right, draw, shade, top color = yellow, minimum width=1.5cm, minimum height=1cm] {FE80};
\draw (1.5,1.5) node [right, draw, minimum width=4cm, minimum height=1cm] {0...0};
\draw (5.5,1.5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.7, 2.2) node {\tiny{10}};
\draw (3.5, 2.2) node {\tiny{54}};
\draw (8, 2.2) node {\tiny{64}};

\draw [snake=brace, mirror snake] (5.5, 0.8) -- (10.3, 0.8) node [below, midway] {\tiny{link address}} node [below = 8pt, midway] {\tiny{auto-configuration}} ;
</tikz>

Ces adresses sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins (''neighbor discovery'') et de découverte de routeurs (''router discovery''). Ce sont de nouveaux dispositifs, le premier supplantant en particulier le protocole ARP (''Address Resolution Protocol''), qui permettent à un réseau local de se configurer automatiquement (voir [[Découverte de voisins]]). Elles sont également largement utilisées par les protocoles de routage soit pour l'échange de données (cf. RIPng, OSPFv3), soit dans les tables de routage puisque le champ ''prochain routeur'' est toujours un équipement directement accessible sur le lien.
{{HorsTexte|Unicité sur le lien|Les adresses lien-local sont uniques à l'intérieur d'un lien. Le protocole de détection de duplication d'adresses (voir [[Configuration automatique#DAD|Détection d'adresse dupliquée]]) permet de s'en assurer. Par contre la duplication d'une adresse lien-local entre deux liens différents, ou entre deux interfaces d'un même nœud est autorisée.}}

Un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type lien-local.

Le fait que ces adresses aient une portée très faible les limite dans la pratique au cas où un démarrage automatique (''bootstrap'') est nécessaire. Leur usage ne doit pas être généralisé dans les applications classiques en régime stabilisé.

==== Portée de l'adresse (''scoped address'') ====

Une adresse lien-local (ou multicast) n'indique pas intrinsèquement l'interface de sortie, puisque toutes les interfaces partagent le même préfixe <tt>fe80::/10</tt>. Il faut donc indiquer de manière explicite sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère "%". Sous Linux, un argument, généralement <tt>-I</tt> permet de la désigner.

===Unique Local Address===

Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local Address''). Ces adresses sont destinées à une utilisation locale. Elles ne sont pas définies pour être routées dans l'Internet, mais seulement au sein d'une zone limitée telle qu'un site ou entre un nombre limité de sites. La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits

Les adresses uniques locales sont créées en utilisant un identifiant global (''Global ID'') généré pseudo-aléatoirement. Ces adresses suivent le format suivant :

* <tt>Prefix</tt> (7 bits) : <tt>FC00::/7</tt> préfixe identifiant les adresses IPv6 locales (''ULA'')
* <tt>L</tt> (1 bit) : Positionné à 1, le préfixe est assigné localement. La valeur 0 est réservée pour une utilisation future.
* <tt>Global ID</tt> (40 bits) : Identifiant global utilisé pour la création d'un préfixe ''unique'' (''Globally Unique Prefix'').
* <tt>Subnet ID</tt> (16 bits) : Identifiant d'un sous réseau à l'intérieur du site.
* <tt>Interface ID</tt> (64 bits) : L'indentifiant d'interface tel que défini dans [[Identifiant d'interface]].

Le site http://www.sixxs.net/tools/grh/ula/ permet de créer et d'enregistrer son adresse ULA à partir d'une adresse MAC.

<tikz title="Unique Local Addresses">
\clip (0, 0) rectangle (11,4);
% \draw[help lines] (0,0) grid (10,3);

% \draw (0, 3.6) node [right] {Unique Local IPv6 Unicast Addresses:};

\draw (0,2) node [right, draw, shade, top color = yellow, minimum width=1.5cm, minimum height=1cm] {FD};
\draw (1.5,2) node [right, draw, shade, top color = green, minimum width=3cm, minimum height=1cm] {Random Value};
\draw (4.5,2) node [right, draw, shade, top color = blue, minimum width=1cm, minimum height=1cm] {SID};
\draw (5.5,2) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.7, 2.7) node {\tiny{8}};
\draw (2.7, 2.7) node {\tiny{40}};
\draw (4.7, 2.7) node {\tiny{16}};
\draw (8, 2.7) node {\tiny{64}};

\draw [snake=brace, mirror snake] (0, 1.20) -- (4.5, 1.20) node [below, midway] {\tiny{private topology}} node [below = 8pt, midway] {\tiny{Not Routable in the Internet}} ;
\draw [snake=brace, mirror snake] (4.5, 1.20) -- (5.5, 1.20) node [below, midway] {\tiny{local topology}};
\draw [snake=brace, mirror snake] (5.5, 1.20) -- (10.3, 1.20) node [below, midway] {\tiny{link address}} ;
</tikz>

Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé (comme <tt>10/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé vers l'adressage public.

Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif en bordure de réseau va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66 a été renommé NPTv6 {''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4.

~

Les préfixes ULA se caractérise par une séquence aléatoire de 40 bits après le préfixe <tt>FC::/7</tt>. Cette valeur unique permet d'éviter les problèmes rencontrés en IPv4 lors de la fusion de réseau privées. Le risque de collision entre deux valeurs aléatoires sur 40 bits étant relativement faible, si deux réseaux fusionnent le fait d'avoir des préfixes uniques permet d'éviter des problèmes d'interconnexion si les SID ne le sont pas.

= Structuration de l'identifiant d'interface (IID) =

Si initialement pour des raisons d'auto-configuration, l'identifiant d'interface devait toujours être dérivé de l'adresse de niveau 2, c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits:

* manuelle,
* basée sur l'adresse de niveau 2 de l'interface,
* aléatoire,
* cryptographique.

== Manuel ==
{{HorsTexte|Le resolveur DNS|Le résolveur DNS est le cas le plus flagrant; chaque machine sur le réseau doit être configurée avec l'adresse IPv6 du serveur DNS. En cas de changement de carte réseau, l'ensemble des machines du domaine devront être reconfigurées. Si l'on ne souhaite pas utiliser des protocoles de configuration automatique de type DHCPv6, il est préférable d'attribuer au résolveur DNS une adresse manuelle.}}
Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces, car dans ce cas l'adresse IPv6 est facilement mémorisable, et le serveur peut être accessible même si le DNS n'est pas actif.
Il existe plusieurs techniques plus ou moins mnémotechniques :
* incrémenter l'identifiant d'interface à chaque nouveau serveur créé

<tt>2001:DB8:1234:1::1</tt>
<tt>2001:DB8:1234:1::2</tt>
...

* reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple si un serveur a comme adresse IPv4 <tt>192.0.2.123</tt>, son adresse IPv6 sera :

<tt>2001:DB8:1234:1::7B</tt>
ou plus simplement
<tt>2001:DB8:1234:1::123</tt>

* reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à taper :

<tt>2001:DB8:1234:1::192.0.2.123</tt>

== Dérivé de l'adresse de l'interface==

L'avantage d'utiliser une adresse de niveau 2 pour construire un identifiant d'interface est que l'unicité de cette valeur est presque toujours assurée. En plus, cette valeur est stable tant que la carte réseau de la machine n'est pas changée. Par contre, ces valeurs sont difficilement mémorisables.

Les adresses lien-local sont construites en utilisant ce type d'identifiant. Par contre pour les adresses globales, il est conseillé de ne les utiliser que pour les machines client et de préférer les identifiants d'interface manuels pour les serveurs.

Ces identifiants d'interface étant stables dans le temps, à chaque fois qu'un individu change de réseau, il change de préfixe, mais garde le même identifiant d'interface. Ce dernier pourrait donc servir à tracer les déplacements d'un individu. Le risque est faible, car les cookies mis en place par les serveurs web sont bien plus efficaces, mais ils ne s'agit plus d'un problème réseau. Autre désavantage, comme les adresses MAC contiennent l'identification du matériel, il est possible d'indiquer à l'exterieur du réseau quel type de materiel est utilisé et donner des indications.

Si ces inconvénients sont jugés importants par l'entreprise, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement.

=== EUI-64 ===

<tikz title="Transformation d'une adresse MAC en identifiant d'interface">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{u}g}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (5, 1.5) node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};

</tikz>

L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (firewire) ou IEEE 802.15.4 (réseau de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64.

Il existe plusieurs méthodes pour construire l'identifiant :
{{HorsTexte|Ordre de transmission|L'ordre des bits ne doit pas porter à confusion. Dans la représentation numérique des valeurs, le premier bit transmis est le bit de poids faible, c'est-à-dire le bit de droite. Ainsi sur le support physique le bit <tt>g</tt>, puis le bit <tt>u</tt> puis les bits suivants sont transmis. }}

* Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure décrite figure Identificateur global IEEE EUI-64.
: Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802, identifient le constructeur et les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits <tt>u</tt> (septième bit du premier octet) et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :
:* <tt>u</tt> (Universel) vaut <tt>0</tt> si l'identifiant EUI-64 est universel,
:* <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g = 0</tt>), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g = 1</tt>), par exemple une adresse de multicast.

<tikz title="Identificateur d'interface dérivé d'une EUI-64">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (5, 1.5) node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};

</tikz>
* L'identifiant d'interface à 64 bits est dérivé de l'EUI-64 en inversant le bit <tt>u</tt> (cf. figure Identificateur d'interface dérivé d'une EUI-64). En effet, pour la construction des adresses IPv6, on a préféré utiliser <tt>1</tt> pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur <tt>0</tt> pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de <tt>1</tt>.

===MAC-48===

<tikz title="Transformation d'une adresse MAC en identifiant d'interface">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\only<2-> {
\draw (3, 4.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
\draw (4, 4.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (3, 4.25) rectangle+(3, 0.5);

\draw (0,4.5) node [right] {MAC-48};

\draw (6, 4.5) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (2, 3) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
\draw (3, 3) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 2.75) rectangle+(3, 0.5);

\draw (7, 3) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (6,4.5) -- (6, 4) -- (5, 3.5) -- (5, 3);
\draw (6,4) -- (7, 3.5) -- (7, 3);
\draw (3, 4.5) -- (3, 4) -- (2, 3.5) -- (2, 3);
\draw (9, 4.5) -- (9, 4) -- (10, 3.5) -- (10, 3);

\draw (5, 3) node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};

\draw (0,3) node [right] {EUI-64};
}

\only<3-> {

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (7, 1.5) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (5, 1.5) node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};

\draw (2,3) -- (2, 1.5);
\draw (10,3) -- (10, 1.5);
\draw (0,1.5) node [right] {IID};
}

</tikz>

* Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi). L'adresse est tout d'abord convertie en EUI-64, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure ci-contre illustre ce processus.

===Cas Particuliers===
* Si une interface possède une adresse locale unique sur le lien, mais non universelle (par exemple le format d'adresse IEEE 802 sur 2 octets ou une adresse sur un réseau Appletalk), l'identifiant d'interface est construit à partir de cette adresse en rajoutant des 0 en tête pour atteindre 64 bits.

{{HorsTexte|Erreur de l'IETF|À noter que l'IETF s'est trompée quand elle a défini l'algorithme de conversion. En effet, l'ajout de la valeur <tt>0xFFFE</tt> concerne les EUI-48, c'est-à-dire des identifiants, alors qu'Ethernet utilise des MAC-48, c'est-à-dire des adresses (ils servent à transporter des trames vers le bon destinataire). La bonne valeur aurait été <tt>0xFFFF</tt>. Mais cette erreur n'a aucune conséquence pour l'identification des équipements, elle n'a donc pas été corrigée par la suite.}}

* Si une interface ne possède aucune adresse (par exemple l'interface utilisée pour les liaisons PPP), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle ou bien une génération aléatoire, avec le bit u positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, et devra être résolu manuellement.

== Valeur aléatoire ==

L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pourrait poser des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur, qui même s'il se déplace de réseau en réseau garde ce même identifiant. Il serait alors possible de traquer un individu utilisant un portable, chez lui, au bureau, lors de ses déplacements. Ce problème est similaire à l'identificateur placé dans les processeurs Pentium III.

[[image:Windows7-IIDalea.png|500px|right]]

Pour couper court à toute menace de boycott d'un protocole qui « menacerait la vie privée », il a été proposé d'autres algorithmes de construction d'un identifiant d'interface basé sur des tirages aléatoires (voir RFC 3041). Un utilisateur particulièrement méfiant pourrait valider ces mécanismes. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme comme MD5 à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.

Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globale. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (i.e. les applications serveur). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours et sert aux applications client. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur Linux et les système d'exploitation BSD comme Mac OS.

Bien entendu pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse ou que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit impossible.

En contre partie, il est plus difficile à un administrateur réseau de filtrer les machines puisque celles-ci changent périodiquement d'adresses.

== Cryptographique ==

{{HorsTexte|Encore un sujet de recherche|L'usage de ces adresses n'est pas encore généralisé. Shim6 pour la gestion de la multi-domiciliation ou SEND pour sécuriser la découverte de voisins y ont recours.}}
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.

=Adresses Multicast=
{{HorsTexte|Portée et portée|Il ne faut pas confondre la portée d'une adresse link-local ou multicast qui désigne l'interface par laquelle sera émis le paquet et la portée d'un groupe multicast qui désigné l'étendue de la couverture}}
Cette section décrit brièvement le système d'adressage multicast IPv6 et ne s'intéresse qu'aux adresses utilisées localement par les protocoles directement liés à IPv6 (Découverte de voisins, DHCPv6,...). Pour plus de détails sur le multicast en général, se reporter au chapitre [[Multicast]]. La figure Structure de l'adresse IPv6 Multicast donne le format de l'adresse IPv6 de multicast décrite dans le RFC 3513.

<tikz title="Structure de l'adresse IPv6 Multicast">
\clip (0, 1) rectangle (11,4);
% \draw[help lines] (0,0) grid (10,4 );

% \draw (0, 3.6) node [right] {Generic Format:};

\draw (0,2) node [right, draw, shade, top color = yellow, minimum width=2cm, minimum height=1cm] {FF};
\draw (2,2) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tiny{\tt{xRPT}}};
\draw (3,2) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tiny{scope}};
\draw (4,2) node [right, draw, shade, top color = black!50, minimum width=6cm, minimum height=1cm] {Group ID};

\draw (1, 2.7) node {\tiny{8}};
\draw (2.5, 2.7) node {\tiny{4}};
\draw (3.5, 2.7) node {\tiny{4}};
\draw (7, 2.7) node {\tiny{112}};

</tikz>

Les adresses multicast IPv6 sont dérivées du préfixe <tt>FF00::/8</tt>. Le champ drapeaux de 4 bits est défini de la manière suivante :

* Seul le bit <tt>T</tt> (comme ''Transient'') du champ drapeaux est initialement décrit dans le RFC 3513. La valeur <tt>0</tt> indique une adresse multicast bien connue gérée par une autorité. La valeur <tt>1</tt> indique une valeur temporaire.
* Les bits <tt>P</tt> et <tt>R</tt> sont décrits dans le RFC 3306 et le draft Internet sur embedded-RP (RFC 3956).
* Le bit de poids fort du champ drapeaux n'est pas encore attribué.

Le champ drapeaux permet de définir plusieurs types d'adresses multicast IPv6 qui seront décrits dans les sections suivantes.

Le champ scope de l'adresse multicast IPv6 permet d'en limiter la portée (''scope'' en anglais). En IPv4, la portée d'un paquet est limitée par le champ TTL (''Time To Live''), de même des préfixes peuvent être définis pour identifier des adresses à portée réduite. Les valeurs suivantes sont définies dans la RFC 2373 :

* 1 - node-local : Les paquets ne sortent pas de la machine, cette adresse sert pour la communication entre les applications.
* 2 - link-local : La portée se limite au réseau local, les paquets ne peuvent pas traverser les routeurs multicast. Cette valeur est utilisée en particulier par le protocole de découverte des voisins.
* 3 - subnet-local : Ce type n'est pas officiellement défini, mais se retrouve dans certains documents. Il permet de faire la différence entre un lien physique et un lien logique (regroupement de plusieurs liens physiques) partageant le même préfixe IPv6.
* 4 - admin-local
* 5 - site-local
* 8 - organisation-local
* E - global
* Les portées 0 et F sont réservées.

http://www.iana.org/assignments/ipv6-multicast-addresses donne les adresses multicast définies. Le tableau ci-dessous liste les plus utilisées :

{|
!Adresse multicast !! usage
|-style="background:silver"
| FF01::1 || All Nodes Address
|-
| FF01::2 || All Routers Address
|-style="background:silver"
| FF02::1 || All Nodes Address
|-
| FF02::2 || All Routers Address
|-style="background:silver"
| FF02::5 || OSPFIGP
|-
| FF02::6 || OSPFIGP Designated Routers
|-style="background:silver"
| FF02::9 || RIP Routers
|-
| FF02::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-style="background:silver"
| FF02::1:2 || All-dhcp-agents
|-
| FF03::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-style="background:silver"
| FF04::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-
| FF05::2 || All Routers Address
|-style="background:silver"
| FF05::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-
| FF05::1:3 || All-dhcp-servers
|-style="background:silver"
| FF0X::101 || Network Time Protocol (NTP)
|}

==Adressage Multicast Sollicité==

IPv6 interdit l'utilisation de la diffusion généralisée (Broadcast) lorsque le Multicast est disponible. Ainsi les protocoles comme Neighbor Discovery, chargé de faire le lien entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse de Multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>FF02::1</tt> (tous les équipements sur le lien, l'utilisation des adresses de multicast sollicité permet de réduire considérablement le nombre d'équipements qui recevront la requête.

<tikz title="Construction de l'adresse de Multicast sollicité">
\clip (0, 0) rectangle (10,4);
%\draw[help lines] (0,0) grid (10,4 );

\draw (2, 3.75) node (mac) [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{01-02-03-04-05-06}}};

\draw (0, 2.75) node (LL) [right, draw, shade, top color = green!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{FE80::0102:03FF:FE04:0506}}};

\draw (4, 2.75) node (GP) [right, draw, shade, top color = green!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{GP:0102:03FF:FE04:0506}}};

\draw [->] (mac) -- (LL);
\draw [->] (mac) -- (GP);

\draw (8, 2.75) node (manuel) [right, draw, shade, top color = green!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{GP::1}}};

\draw (2.5, 1.75) node (MS1) [right, draw, shade, top color = red!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{FF02::1:FF04:0506}}};
\draw [->] (LL) -- (MS1);
\draw [->] (GP) -- (MS1);

\draw (7.4, 1.75) node (MS2) [right, draw, shade, top color = red!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{FF02::1:FF00:0001}}};
\draw [->] (manuel) -- (MS2);

\draw (2.5, 0.75) node (mac2) [right, draw, shade, top color = blue!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{33-33-FF-04-05-06}}};
\draw [->] (MS1) -- (mac2);

\draw (7.4, 0.75) node (mac3) [right, draw, shade, top color = blue!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{33-33-FF-00-00-01}}};
\draw [->] (MS2) -- (mac3);
</tikz>

La figure Construction de l'adresse de Multicast sollicité montre comment l'on passe d'une adresse IPv6 unicast à une adresse de multicast sollicité. Il s'agit de prendre les 3 derniers octets de l'adresse unicast que l'on concatène avec le préfixe IPv6 multicast <tt>FF02::1:FF00:0/104</tt>.

Dans l'exemple, les deux adresses dérivant d'une adresse MAC conduisent à la même adresse de multicast sollicité, tandis que la configuration manuelle d'une interface conduit à la construction d'une autre adresse de multicast sollicité. On peut noter que le risque que deux machines sur un lien aient la même adresse de multicast sollicité est très faible. Pour celles dérivant d'une adresse MAC, il faudrait que les 3 derniers octets soient identiques, ce qui est impossible chez un même constructeur et la probabilité d'avoir, sur un même lien, des cartes de deux constructeurs différents se terminant par les mêmes 3 derniers octets est très faible. Pour la numérotation manuelle des interfaces, une machine ayant l'adresse <tt>GP::0100:0001</tt> conduirait à construire la même adresse de multicast sollicité <tt>FF02::1:FF00:0001</tt>, mais cette numérotation manuelle des interfaces n'est pas logique.

{{HorsTexte|Sollicitation des voisins|L'algorithme de découverte des adresses de niveau 3 des voisins (inclus dans Neighbor Discovery) fonctionne de la manière suivante. La machine qui recherche un voisin dont elle connait l'adresse IPv6, effectue l'algorithme décrit précédemment. Elle émet la requête en utilisant l'adresse MAC obtenue. Seule la machine qui possède cette adresse est abonnée à ce groupe, elle sera donc la seule à traiter la requête et à y répondre.}}

L'exemple se poursuit par la transformation de l'adresse de Multicast au niveau IPv6 en adresse de multicast de niveau 2. Elle est très spécifique à la technologie et à la manière dont est mis en œuvre le multicast au niveau 2. Pour les réseaux Ethernet (et dérivés comme le Wi-Fi), les 4 derniers octets de l'adresse multicast sollicité sont ajoutés au préfixe <tt>33-33</tt>.
{{Suivi| Introduction|Introduction | AdressageBis-MeO|Mises en Oeuvre}}

AdressageBis-Fondamentaux

2011-12-25T19:34:20Z

Ltoutain: /* Unique Local Address */

{{Suivi| Introduction|Introduction | AdressageBis-MeO|Mises en Oeuvre}}

Le format et la représentation des adresses sont les modifications les plus visibles pour l'utilisateur expérimenté et l'ingénieur réseau dans cette nouvelle version du protocole. En effet la taille de l'adresse reste fixe mais passe de 32 à 128 bits. Même si les principes sont fortement similaires à ceux employés dans IPv4, cet adressage apparaît à première vue beaucoup plus complexe. Il est intéressant d'en comprendre le principe et les règles d'attribution avant d'aborder les aspects protocolaires.

Ce chapitre présente les différents types d'adresses. Il explique en détail le plan d'adressage agrégé qui a été retenu pour construire l'Internet IPv6. Il décrit également la manière de constituer une adresse IPv6.

= Aspects fondamentaux de l'adressage IPv6=

==<div id="representation">Représentation des adresses ==

La représentation textuelle d'une adresse IPv6 se fait en découpant le mot de 128 bits de l'adresse en 8 mots de 16 bits séparés par le caractère «:», chacun d'eux étant représenté en hexadécimal. Par exemple :

<tt>2001:0DB8:0000:0000:0400:A987:6543:210F</tt>

Dans un champ, il n'est pas nécessaire d'écrire les zéros placés en tête :

<tt>2001:DB8:0:0:400:A987:6543:210F</tt>

En outre plusieurs champs nuls consécutifs peuvent être abrégés par «::». Ainsi l'adresse précédente peut s'écrire comme suit :

<tt>2001:DB8::400:A987:6543:210F</tt>

Naturellement, pour éviter toute ambiguïté, l'abréviation «::» ne peut apparaître qu'une fois au plus dans une adresse. Les cas extrêmes sont l'adresse indéfinie (utilisée pour désigner les routes par défaut) à tous les bits à zéro et qui se note de manière compacte :

<tt>::</tt>

et l'adresse de bouclage (loopback), équivalent du préfixe <tt>127/8</tt> dont tous les bits sont à zéro sauf le dernier et qui s'écrit :

<tt>::1</tt>

La représentation des préfixes réseau IPv6 est similaire à la notation CIDR RFC 1519 utilisée pour les préfixes IPv4. Un préfixe IPv6 est donc représenté par la notation :

adresse-ipv6/longueur-du-préfixe-en-bits

Les formes abrégées avec «::» sont autorisées.

<tt>2001:0DB8:7654:3210:0000:0000:0000:0000/64
2001:DB8:7654:3210:0:0:0:0/64
2001:DB8:7654:3210::/64</tt>

Le seul piège de cette notation vient des longueurs de préfixes qui ne sont pas en frontière de «:». Ainsi le préfixe <tt>3EDC:BA98:7654:3::/56</tt> équivaut en réalité à <tt>3EDC:BA98:7654:0000::/56</tt> car il s'écrit <tt>3EDC:BA98:7654:0003::/56</tt>.

On peut combiner le préfixe réseau avec l'identifiant de l'interface en une seule notation. Ainsi cette adresse IPV6
<tt>2001:DB8:7654:3210:945:1321:ABA8:F4E2/64</tt>
indique que le préfixe réseau est constitué par les 64 premiers bits.

{{HorsTexte|Apprendre à gaspiller|Du fait de sa longueur, une règle de bonne gestion consiste à relâcher les contraintes sur les longueurs de préfixe. Ainsi en utilisant quand cela est possible des multiples de 4 permet d'avoir un préfixe qui tient sur un caractère affiché. Dans l'exemple suivant 47 n'étant pas un multiple de 4, <tt>2001:DB0:1234::/47</tt> représente les préfixes commençant par <tt>2001:DB0:1234</tt> et <tt>2001:DB0:1235</tt>}}

Ces représentations peuvent apparaître beaucoup plus complexes qu'avec IPv4, mais en vérité des adresses logiques ou concises peuvent être constituées au moyen de règles strictes. Ces règles favorisent grandement la manipulation et la mémorisation des adresses comme nous verrons par la suite (cf Adressage global)

Dans certains cas, une adresse (voire plusieurs adresses) IPv4 peut être contenue dans une adresse IPv6. Pour les faire ressortir, la notation classique d'IPv4, c'est à dire 4 octets en représentation décimale séparés par des points, peut être utilisée au sein d'une adresse IPv6. Ainsi :

<tt>::128.12.13.14</tt>

représente une adresse IPv6 composée de 96 bits à 0 suivis des 32 bits de l'adresse IPv4 <tt>128.12.13.14</tt>

Il est pourtant parfois nécessaire de manipuler littéralement des adresses IPv6. Le caractère ":" utilisé pour séparer les mots peut créer des ambiguïtés. C'est le cas avec les URL où il est aussi utilisé pour indiquer le numéro de port. Ainsi l'URL

<tt><nowiki>http://2001:DB8:12::1:8000/</nowiki></tt>

peut aussi bien indiquer le port 8000 sur la machine ayant l'adresse IPv6 2001:DB8:12::1, que la machine 2001:DB8:12::1:8000 en utilisant le port par défaut. Pour lever cette ambiguïté, le RFC 2732 propose d'inclure l'adresse IPv6 entre "[ ]". L'adresse précédente s'écrirait :

<tt><nowiki>http://[2001:DB8:12::1]:8000/</nowiki></tt>

ou

<tt><nowiki>http://[2001:DB8:12::1:8000]/</nowiki></tt>

suivant les cas. Cette représentation peut être étendue à d'autres domaines comme X-window ou au protocole de signalisation téléphonique SIP.

== Type des adresses ==

IPv6 reconnaît trois types d'adresses : unicast, multicast et anycast. Le type d'adresse définit la cardinalité de la communication: à combien de destinataire doit être remis le paquet.

Le premier de ces types désigne de manière unique une interface. Un paquet envoyé à une telle adresse, sera donc remis à l'interface ainsi identifiée. Parmi les adresses unicast, on peut distinguer celles qui auront une portée globale, c'est-à-dire désignant sans ambiguïté une destination sur le réseau Internet et celles qui auront une portée locale (lien ou site). Ces dernières ne pourront pas être routées sur l'Internet c'est à dire qu'un paquet comportant une adresse de destination avec une portée locale sera ignoré et éliminé par un routeur de l'Internet. La portée d'une adresse indique en faite la limite de la propriété d'unicité.

Une adresse de type multicast désigne un groupe d'interfaces qui en général appartiennent à des noeuds différents pouvant être situés n'importe où dans l'Internet. Lorsqu'un paquet a pour destination une adresse de type multicast, il est acheminé par le réseau à toutes les interfaces membres de ce groupe.

Il faut noter qu'il n'y a plus d'adresses de type broadcast comme sous IPv4 ; elles sont remplacées par des adresses de type multicast. En effet, l'adresse de broadcast peut être émulée avec une adresse multicast en constituant un groupe qui comporte tous les noeuds. De plus, l'absence de broadcast évite les problèmes de saturation des réseaux locaux commutés. Ainsi un réseau IPV6 passe mieux en terme de facteur d'échelle sur ce type de réseau.

Le dernier type, anycast, est une officialisation de propositions faites pour IPv4 RFC 1546. Comme dans le cas du multicast, une adresse de type anycast désigne un groupe d'interfaces, la différence étant que lorsqu'un paquet a pour destination une telle adresse, il est acheminé à un des éléments du groupe et non pas à tous. C'est, par exemple, le plus proche au sens de la métrique des protocoles de routage. Cet adressage est principalement expérimental, voir [[Anycast|Adresses anycast]].

Certains types d'adresses sont caractérisés par leur préfixe RFC 3513. Le tableau suivant (source : http://www.iana.org/assignments/ipv6-address-space) donne la liste de ces préfixes. La plage «réservée» du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70% de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.

{|
!Préfixe IPv6!!Allouer!!Référence
|-style="background:silver"
|<tt>0000::/8</tt>||[[Autres types d'adresses|Réservé pour la transition et loopback]]||RFC 3513
|-
|<tt>0100::/8</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>0200::/7</tt>||Réservé (ex [[Autres types d'adresses#Les adresses NSAP|NSAP]])||RFC 4048
|-
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 3513
|-style="background:silver"
|<tt>0800::/5</tt>||Réservé||RFC 3513
|-
|<tt>1000::/4</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>2000::/3</tt>||[[Unicast Global]]||RFC 3513
|-
|<tt>4000::/3</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>6000::/3</tt>||Réservé||RFC 3513
|-
|<tt>8000::/3</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>A000::/3</tt>||Réservé||RFC 3513
|-
|<tt>C000::/3</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>E000::/4</tt>||Réservé||RFC 3513
|-
|<tt>F000::/5</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>F800::/6</tt>||Réservé||RFC 3513
|-
|<tt>FC00::/7</tt>||[[Site-local#ula|Unique Local Unicast]]||RFC 4193
|-style="background:silver"
|<tt>FE00::/9</tt> ||Réservé||RFC 3513
|-
|<tt>FE80::/10</tt>||[[Lien-local]]||RFC 3513
|-style="background:silver"
|<tt>FEC0::/10</tt>||Réservé||RFC 3879
|-
|<tt>FF00::/8</tt>||Multicast||RFC 3513
|}

Une interface possèdera généralement plusieurs adresses IPv6. En IPv4 ce comportement est exceptionnel, il est banalisé en IPv6.

= Adressage global : plan d'adressage agrégé =

Ce plan, proposée dans le RFC 3587, précise la structure d'adressage IPv6 définie dans le RFC 3513 en précisant les tailles de chacun des blocs. Il est géré de la même manière que CIDR en IPv4. Une adresse intègre trois niveaux de hiérarchie :

<tikz title="Adresses Globales">
\clip (0.0, 0) rectangle (11.5,7);
% \draw[help lines] (0,0) grid (10,6);

% \draw (0, 6.6) node [right] {Global Unicast Address:};

\draw (0,5) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tt{001}};
\draw (1,5) node [right, draw, shade, top color = green, minimum width=3cm, minimum height=1cm] {Global Prefix};
\draw (4,5) node [right, draw, shade, top color = blue, minimum width=1.5cm, minimum height=1cm] {SID};
\draw (5.5,5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.5, 5.7) node {\tiny{3}};
\draw (2.5, 5.7) node {\tiny{45}};
\draw (4.7, 5.7) node {\tiny{16}};
\draw (8, 5.7) node {\tiny{64}};

\draw [snake=brace, mirror snake] (0, 4.20) -- (4, 4.20) node [below, midway] {\tiny{
\ifthenelse{\equal{francais}{true}}{Topologie Publique}{public topology}}
} node [below = 8pt, midway] {\tiny{given by the provider}} ;
\draw [snake=brace, mirror snake] (4, 4.20) -- (5.5, 4.20) node [below, midway] {\tiny{local topology}} node [below = 8pt, midway] {\tiny{assigned by network engineer}} ;
\draw [snake=brace, mirror snake] (5.5, 4.20) -- (10.3, 4.20) node [below, midway] {\tiny{link address}} node [below = 8pt, midway] {\tiny{auto or manual configuration}} ;
</tikz>

* une topologie publique (appelée '''Global Prefix''') codée sur 48 bits, allouée par le fournisseur d'accès;
* une topologie de site codée sur 16 bits (appelée '''Subnet ID'''). Ce champ permet de coder les numéros de sous réseau du site;
* un [[identifiant d'interface]] sur 64 bits (appelé '''Interface ID''') distinguant les différentes machines sur le lien.

==Structuration du prefixe global (GP)==

{{HorsTexte|Appréhender les tailles|France Télécom a obtenu du RIPE-NCC un <tt>/19</tt>. Si l'on enlève les troix premiers bits <tt>001</tt> désignant le plan d'adressage, il est donc possible d'avoir 216 opérateurs. Sachant qu'il y a 192 pays à l'ONU, ils pourraient chacun abriter 320 opérateurs de la taille de FT, chacun pouvant attribuer jusqu'à 229 <tt>/48</tt>, soit 536 870 912 sites}}

A part le préfixe <tt>2002::</tt> qui est est réservé au mécanisme de transition [[6to4]], cet espace est géré hierarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales ([http://www.iana.org/numbers/ RIR]) des préfixes actuellement de longueur 12 (cf. http://www.iana.org/assignments/ipv6-unicast-address-assignments) qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long. Le site http://www.sixxs.net/tools/grh/ donne en temps réel les allocations de préfixes par région, opérateur et pays.

Il est maintenant admis que le préfixe attribué par un opérateur à ses clients peut également être un <tt>/56</tt>. En effet, si l'on garde l'attribution de préfixe de longueur 48 pour les sites terminaux, et que l'on intègre les réseaux domotiques, les opérateurs peuvent justifier d'un besoin important d'adresses que les autorités régionales ne peuvent leur refuser.

{{ToDo|Ajouter comment obtenir un préfixe auprès de RIPE-NCC}}

==Structuration de l'identifiant de sous-réseau (SID)==

Il n'existe pas de règles pour allouer les identificateurs de sous-réseau au sein d'un site. Plusieurs techniques (non exclusives) peuvent être utilisées :

* numéroter de manière incrémentale les sous-réseaux: 0001, 0002, ... Cette technique est simple a mettre en œuvre dans des réseaux expérimentaux, mais elle peut conduire à un plan d'adressage à plat difficile à mémoriser. Elle peut être utilisée par exemple pour un sous-réseau dédié aux serveurs pour simplifier l'écriture et la mémorisation des adresses.
* utiliser le numéro de VLAN. Elle permet d'éviter de mémoriser plusieurs niveaux de numérotation.
* séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau suivant contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs :

{|
!Communauté !! 4bits !! width="50%"|8bits !! 4bits
|-style="background:silver"
| Infrastructure || 0 || colspan=2 | valeurs spécifiques
|-
| Tests || 1 || colspan=2 | valeurs spécifiques
|-style="background:silver"
| Tunnels || 6 || colspan=2 | allocation de /60 aux utilisateurs
|-
| Invités Wi-Fi || 8 || colspan=2 | valeurs spécifiques
|-style="background:silver"
| Personnels || A || Entité || Sous-Réseaux
|-
| Etudiants || E || Entité || Sous-Réseaux
|-style="background:silver"
| Autres (Start up, etc.) || F || colspan=2 | valeurs spécifiques
|+ Affectation des SID dans une université
|}

Ainsi, le préfixe:
* <tt>2001:DB8:1234::/52</tt> servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs seront prises dans cet espace;
* <tt>2001:DB8:1234:8000::/52</tt> servira pour le réseau Wi-Fi des invités. La manière dont sont gérés les 12 bits restants du SID ne sont pas spécifiés;
* <tt>2001:DB8:1234:E000::/52</tt> servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.

=== Adressage local : adresses lien-local ===

Les adresses de type lien-local (''link local use address'') sont des adresses dont la validité est restreinte à un lien, c'est-à-dire l'ensemble de interfaces directement connectées sans routeur intermédiaire comme par exemple des machines branchées sur un même réseau Ethernet, des machines reliées par une connexion PPP, ou des extrémités d'un tunnel. Les adresses lien-local sont configurées automatiquement à l'initialisation de l'interface et permettent la communication entre nœuds voisins. L'adresse est obtenue en concaténant le préfixe <tt>FE80::/64</tt> aux 64 bits de l'[[Identifiant d'interface|identifiant d'interface]]. L'identifiant d'interface est généralement basé sur l'adresse MAC. Cela ne pose pas de problème de respect de le vie privée car, contrairement aux adresses globales, les adresses lien-local ne sortent jamais du réseau où elles sont utilisées.

<tikz title="Adresses Lien-local">
% \draw (0, 3) node [right] {Link-Local Address:};
\draw (0,1.5) node [right, draw, shade, top color = yellow, minimum width=1.5cm, minimum height=1cm] {FE80};
\draw (1.5,1.5) node [right, draw, minimum width=4cm, minimum height=1cm] {0...0};
\draw (5.5,1.5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.7, 2.2) node {\tiny{10}};
\draw (3.5, 2.2) node {\tiny{54}};
\draw (8, 2.2) node {\tiny{64}};

\draw [snake=brace, mirror snake] (5.5, 0.8) -- (10.3, 0.8) node [below, midway] {\tiny{link address}} node [below = 8pt, midway] {\tiny{auto-configuration}} ;
</tikz>

Ces adresses sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins (''neighbor discovery'') et de découverte de routeurs (''router discovery''). Ce sont de nouveaux dispositifs, le premier supplantant en particulier le protocole ARP (''Address Resolution Protocol''), qui permettent à un réseau local de se configurer automatiquement (voir [[Découverte de voisins]]). Elles sont également largement utilisées par les protocoles de routage soit pour l'échange de données (cf. RIPng, OSPFv3), soit dans les tables de routage puisque le champ ''prochain routeur'' est toujours un équipement directement accessible sur le lien.
{{HorsTexte|Unicité sur le lien|Les adresses lien-local sont uniques à l'intérieur d'un lien. Le protocole de détection de duplication d'adresses (voir [[Configuration automatique#DAD|Détection d'adresse dupliquée]]) permet de s'en assurer. Par contre la duplication d'une adresse lien-local entre deux liens différents, ou entre deux interfaces d'un même nœud est autorisée.}}

Un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type lien-local.

Le fait que ces adresses aient une portée très faible les limite dans la pratique au cas où un démarrage automatique (''bootstrap'') est nécessaire. Leur usage ne doit pas être généralisé dans les applications classiques en régime stabilisé.

==== Portée de l'adresse (''scoped address'') ====

Une adresse lien-local (ou multicast) n'indique pas intrinsèquement l'interface de sortie, puisque toutes les interfaces partagent le même préfixe <tt>fe80::/10</tt>. Il faut donc indiquer de manière explicite sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère "%". Sous Linux, un argument, généralement <tt>-I</tt> permet de la désigner.

===Unique Local Address===

Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local Address''). Ces adresses sont destinées à une utilisation locale. Elles ne sont pas définies pour être routées dans l'Internet, mais seulement au sein d'une zone limitée telle qu'un site ou entre un nombre limité de sites. La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits

Les adresses uniques locales sont créées en utilisant un identifiant global (''Global ID'') généré pseudo-aléatoirement. Ces adresses suivent le format suivant :

* <tt>Prefix</tt> (7 bits) : <tt>FC00::/7</tt> préfixe identifiant les adresses IPv6 locales (''ULA'')
* <tt>L</tt> (1 bit) : Positionné à 1, le préfixe est assigné localement. La valeur 0 est réservée pour une utilisation future.
* <tt>Global ID</tt> (40 bits) : Identifiant global utilisé pour la création d'un préfixe ''unique'' (''Globally Unique Prefix'').
* <tt>Subnet ID</tt> (16 bits) : Identifiant d'un sous réseau à l'intérieur du site.
* <tt>Interface ID</tt> (64 bits) : L'indentifiant d'interface tel que défini dans [[Identifiant d'interface]].

Le site http://www.sixxs.net/tools/grh/ula/ permet de créer et d'enregistrer son adresse ULA à partir d'une adresse MAC.

<tikz title="Unique Local Addresses">
\clip (0, 0) rectangle (11,4);
% \draw[help lines] (0,0) grid (10,3);

% \draw (0, 3.6) node [right] {Unique Local IPv6 Unicast Addresses:};

\draw (0,2) node [right, draw, shade, top color = yellow, minimum width=1.5cm, minimum height=1cm] {FD};
\draw (1.5,2) node [right, draw, shade, top color = green, minimum width=3cm, minimum height=1cm] {Random Value};
\draw (4.5,2) node [right, draw, shade, top color = blue, minimum width=1cm, minimum height=1cm] {SID};
\draw (5.5,2) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.7, 2.7) node {\tiny{8}};
\draw (2.7, 2.7) node {\tiny{40}};
\draw (4.7, 2.7) node {\tiny{16}};
\draw (8, 2.7) node {\tiny{64}};

\draw [snake=brace, mirror snake] (0, 1.20) -- (4.5, 1.20) node [below, midway] {\tiny{private topology}} node [below = 8pt, midway] {\tiny{Not Routable in the Internet}} ;
\draw [snake=brace, mirror snake] (4.5, 1.20) -- (5.5, 1.20) node [below, midway] {\tiny{local topology}};
\draw [snake=brace, mirror snake] (5.5, 1.20) -- (10.3, 1.20) node [below, midway] {\tiny{link address}} ;
</tikz>

Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé (comme <tt>10/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé vers l'adressage public.

Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif en bordure de réseau va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66 a été renommé NPTv6 {''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4.

~

Les préfixes ULA se caractérise par une séquence aléatoire de 40 bits après le préfixe <tt>FC::/7</tt>. Cette valeur unique permet d'éviter les problèmes rencontrés en IPv4 lors de la fusion de réseau privées. Le risque de collision entre deux valeurs aléatoires sur 40 bits étant relativement faible, si deux réseaux fusionnent le fait d'avoir des préfixes uniques permet d'éviter des problèmes d'interconnexion si les SID ne le sont pas.

= Structuration de l'identifiant d'interface (IID) =

Si initialement pour des raisons d'auto-configuration, l'identifiant d'interface devait toujours être dérivé de l'adresse de niveau 2, c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits:

* manuelle,
* basée sur l'adresse de niveau 2 de l'interface,
* aléatoire,
* cryptographique.

== Manuel ==
{{HorsTexte|Le resolveur DNS|Le résolveur DNS est le cas le plus flagrant; chaque machine sur le réseau doit être configurée avec l'adresse IPv6 du serveur DNS. En cas de changement de carte réseau, l'ensemble des machines du domaine devront être reconfigurées. Si l'on ne souhaite pas utiliser des protocoles de configuration automatique de type DHCPv6, il est préférable d'attribuer au résolveur DNS une adresse manuelle.}}
Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces, car dans ce cas l'adresse IPv6 est facilement mémorisable, et le serveur peut être accessible même si le DNS n'est pas actif.
Il existe plusieurs techniques plus ou moins mnémotechniques :
* incrémenter l'identifiant d'interface à chaque nouveau serveur créé

<tt>2001:DB8:1234:1::1</tt>
<tt>2001:DB8:1234:1::2</tt>
...

* reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple si un serveur a comme adresse IPv4 <tt>192.0.2.123</tt>, son adresse IPv6 sera :

<tt>2001:DB8:1234:1::7B</tt>
ou plus simplement
<tt>2001:DB8:1234:1::123</tt>

* reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à taper :

<tt>2001:DB8:1234:1::192.0.2.123</tt>

== Dérivé de l'adresse de l'interface==

L'avantage d'utiliser une adresse de niveau 2 pour construire un identifiant d'interface est que l'unicité de cette valeur est presque toujours assurée. En plus, cette valeur est stable tant que la carte réseau de la machine n'est pas changée. Par contre, ces valeurs sont difficilement mémorisables.

Les adresses lien-local sont construites en utilisant ce type d'identifiant. Par contre pour les adresses globales, il est conseillé de ne les utiliser que pour les machines client et de préférer les identifiants d'interface manuels pour les serveurs.

Ces identifiants d'interface étant stables dans le temps, à chaque fois qu'un individu change de réseau, il change de préfixe, mais garde le même identifiant d'interface. Ce dernier pourrait donc servir à tracer les déplacements d'un individu. Le risque est faible, car les cookies mis en place par les serveurs web sont bien plus efficaces, mais ils ne s'agit plus d'un problème réseau. Autre désavantage, comme les adresses MAC contiennent l'identification du matériel, il est possible d'indiquer à l'exterieur du réseau quel type de materiel est utilisé et donner des indications.

Si ces inconvénients sont jugés importants par l'entreprise, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement.

=== EUI-64 ===

<tikz title="Transformation d'une adresse MAC en identifiant d'interface">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{u}g}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (5, 1.5) node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};

</tikz>

L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (firewire) ou IEEE 802.15.4 (réseau de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64.

Il existe plusieurs méthodes pour construire l'identifiant :
{{HorsTexte|Ordre de transmission|L'ordre des bits ne doit pas porter à confusion. Dans la représentation numérique des valeurs, le premier bit transmis est le bit de poids faible, c'est-à-dire le bit de droite. Ainsi sur le support physique le bit <tt>g</tt>, puis le bit <tt>u</tt> puis les bits suivants sont transmis. }}

* Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure décrite figure Identificateur global IEEE EUI-64.
: Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802, identifient le constructeur et les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits <tt>u</tt> (septième bit du premier octet) et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :
:* <tt>u</tt> (Universel) vaut <tt>0</tt> si l'identifiant EUI-64 est universel,
:* <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g = 0</tt>), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g = 1</tt>), par exemple une adresse de multicast.

<tikz title="Identificateur d'interface dérivé d'une EUI-64">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (5, 1.5) node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};

</tikz>
* L'identifiant d'interface à 64 bits est dérivé de l'EUI-64 en inversant le bit <tt>u</tt> (cf. figure Identificateur d'interface dérivé d'une EUI-64). En effet, pour la construction des adresses IPv6, on a préféré utiliser <tt>1</tt> pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur <tt>0</tt> pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de <tt>1</tt>.

===MAC-48===

<tikz title="Transformation d'une adresse MAC en identifiant d'interface">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\only<2-> {
\draw (3, 4.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
\draw (4, 4.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (3, 4.25) rectangle+(3, 0.5);

\draw (0,4.5) node [right] {MAC-48};

\draw (6, 4.5) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (2, 3) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
\draw (3, 3) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 2.75) rectangle+(3, 0.5);

\draw (7, 3) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (6,4.5) -- (6, 4) -- (5, 3.5) -- (5, 3);
\draw (6,4) -- (7, 3.5) -- (7, 3);
\draw (3, 4.5) -- (3, 4) -- (2, 3.5) -- (2, 3);
\draw (9, 4.5) -- (9, 4) -- (10, 3.5) -- (10, 3);

\draw (5, 3) node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};

\draw (0,3) node [right] {EUI-64};
}

\only<3-> {

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (7, 1.5) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (5, 1.5) node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};

\draw (2,3) -- (2, 1.5);
\draw (10,3) -- (10, 1.5);
\draw (0,1.5) node [right] {IID};
}

</tikz>

* Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi). L'adresse est tout d'abord convertie en EUI-64, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure ci-contre illustre ce processus.

===Cas Particuliers===
* Si une interface possède une adresse locale unique sur le lien, mais non universelle (par exemple le format d'adresse IEEE 802 sur 2 octets ou une adresse sur un réseau Appletalk), l'identifiant d'interface est construit à partir de cette adresse en rajoutant des 0 en tête pour atteindre 64 bits.

{{HorsTexte|Erreur de l'IETF|À noter que l'IETF s'est trompée quand elle a défini l'algorithme de conversion. En effet, l'ajout de la valeur <tt>0xFFFE</tt> concerne les EUI-48, c'est-à-dire des identifiants, alors qu'Ethernet utilise des MAC-48, c'est-à-dire des adresses (ils servent à transporter des trames vers le bon destinataire). La bonne valeur aurait été <tt>0xFFFF</tt>. Mais cette erreur n'a aucune conséquence pour l'identification des équipements, elle n'a donc pas été corrigée par la suite.}}

* Si une interface ne possède aucune adresse (par exemple l'interface utilisée pour les liaisons PPP), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle ou bien une génération aléatoire, avec le bit u positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, et devra être résolu manuellement.

== Valeur aléatoire ==

L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pourrait poser des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur, qui même s'il se déplace de réseau en réseau garde ce même identifiant. Il serait alors possible de traquer un individu utilisant un portable, chez lui, au bureau, lors de ses déplacements. Ce problème est similaire à l'identificateur placé dans les processeurs Pentium III.

[[image:Windows7-IIDalea.png|500px|right]]

Pour couper court à toute menace de boycott d'un protocole qui « menacerait la vie privée », il a été proposé d'autres algorithmes de construction d'un identifiant d'interface basé sur des tirages aléatoires (voir RFC 3041). Un utilisateur particulièrement méfiant pourrait valider ces mécanismes. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme comme MD5 à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.

Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globale. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (i.e. les applications serveur). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours et sert aux applications client. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur Linux et les système d'exploitation BSD comme Mac OS.

Bien entendu pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse ou que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit impossible.

En contre partie, il est plus difficile à un administrateur réseau de filtrer les machines puisque celles-ci changent périodiquement d'adresses.

== Cryptographique ==

{{HorsTexte|Encore un sujet de recherche|L'usage de ces adresses n'est pas encore généralisé. Shim6 pour la gestion de la multi-domiciliation ou SEND pour sécuriser la découverte de voisins y ont recours.}}
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.

=Adresses Multicast=
{{HorsTexte|Portée et portée|Il ne faut pas confondre la portée d'une adresse link-local ou multicast qui désigne l'interface par laquelle sera émis le paquet et la portée d'un groupe multicast qui désigné l'étendue de la couverture}}
Cette section décrit brièvement le système d'adressage multicast IPv6 et ne s'intéresse qu'aux adresses utilisées localement par les protocoles directement liés à IPv6 (Découverte de voisins, DHCPv6,...). Pour plus de détails sur le multicast en général, se reporter au chapitre [[Multicast]]. La figure Structure de l'adresse IPv6 Multicast donne le format de l'adresse IPv6 de multicast décrite dans le RFC 3513.

<tikz title="Structure de l'adresse IPv6 Multicast">
\clip (0, 1) rectangle (11,4);
% \draw[help lines] (0,0) grid (10,4 );

% \draw (0, 3.6) node [right] {Generic Format:};

\draw (0,2) node [right, draw, shade, top color = yellow, minimum width=2cm, minimum height=1cm] {FF};
\draw (2,2) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tiny{\tt{xRPT}}};
\draw (3,2) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tiny{scope}};
\draw (4,2) node [right, draw, shade, top color = black!50, minimum width=6cm, minimum height=1cm] {Group ID};

\draw (1, 2.7) node {\tiny{8}};
\draw (2.5, 2.7) node {\tiny{4}};
\draw (3.5, 2.7) node {\tiny{4}};
\draw (7, 2.7) node {\tiny{112}};

</tikz>

Les adresses multicast IPv6 sont dérivées du préfixe <tt>FF00::/8</tt>. Le champ drapeaux de 4 bits est défini de la manière suivante :

* Seul le bit <tt>T</tt> (comme ''Transient'') du champ drapeaux est initialement décrit dans le RFC 3513. La valeur <tt>0</tt> indique une adresse multicast bien connue gérée par une autorité. La valeur <tt>1</tt> indique une valeur temporaire.
* Les bits <tt>P</tt> et <tt>R</tt> sont décrits dans le RFC 3306 et le draft Internet sur embedded-RP (RFC 3956).
* Le bit de poids fort du champ drapeaux n'est pas encore attribué.

Le champ drapeaux permet de définir plusieurs types d'adresses multicast IPv6 qui seront décrits dans les sections suivantes.

Le champ scope de l'adresse multicast IPv6 permet d'en limiter la portée (''scope'' en anglais). En IPv4, la portée d'un paquet est limitée par le champ TTL (''Time To Live''), de même des préfixes peuvent être définis pour identifier des adresses à portée réduite. Les valeurs suivantes sont définies dans la RFC 2373 :

* 1 - node-local : Les paquets ne sortent pas de la machine, cette adresse sert pour la communication entre les applications.
* 2 - link-local : La portée se limite au réseau local, les paquets ne peuvent pas traverser les routeurs multicast. Cette valeur est utilisée en particulier par le protocole de découverte des voisins.
* 3 - subnet-local : Ce type n'est pas officiellement défini, mais se retrouve dans certains documents. Il permet de faire la différence entre un lien physique et un lien logique (regroupement de plusieurs liens physiques) partageant le même préfixe IPv6.
* 4 - admin-local
* 5 - site-local
* 8 - organisation-local
* E - global
* Les portées 0 et F sont réservées.

http://www.iana.org/assignments/ipv6-multicast-addresses donne les adresses multicast définies. Le tableau ci-dessous liste les plus utilisées :

{|
!Adresse multicast !! usage
|-style="background:silver"
| FF01::1 || All Nodes Address
|-
| FF01::2 || All Routers Address
|-style="background:silver"
| FF02::1 || All Nodes Address
|-
| FF02::2 || All Routers Address
|-style="background:silver"
| FF02::5 || OSPFIGP
|-
| FF02::6 || OSPFIGP Designated Routers
|-style="background:silver"
| FF02::9 || RIP Routers
|-
| FF02::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-style="background:silver"
| FF02::1:2 || All-dhcp-agents
|-
| FF03::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-style="background:silver"
| FF04::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-
| FF05::2 || All Routers Address
|-style="background:silver"
| FF05::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-
| FF05::1:3 || All-dhcp-servers
|-style="background:silver"
| FF0X::101 || Network Time Protocol (NTP)
|}

==Adressage Multicast Sollicité==

IPv6 interdit l'utilisation de la diffusion généralisée (Broadcast) lorsque le Multicast est disponible. Ainsi les protocoles comme Neighbor Discovery, chargé de faire le lien entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse de Multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>FF02::1</tt> (tous les équipements sur le lien, l'utilisation des adresses de multicast sollicité permet de réduire considérablement le nombre d'équipements qui recevront la requête.

<tikz title="Construction de l'adresse de Multicast sollicité">
\clip (0, 0) rectangle (10,4);
%\draw[help lines] (0,0) grid (10,4 );

\draw (2, 3.75) node (mac) [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{01-02-03-04-05-06}}};

\draw (0, 2.75) node (LL) [right, draw, shade, top color = green!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{FE80::0102:03FF:FE04:0506}}};

\draw (4, 2.75) node (GP) [right, draw, shade, top color = green!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{GP:0102:03FF:FE04:0506}}};

\draw [->] (mac) -- (LL);
\draw [->] (mac) -- (GP);

\draw (8, 2.75) node (manuel) [right, draw, shade, top color = green!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{GP::1}}};

\draw (2.5, 1.75) node (MS1) [right, draw, shade, top color = red!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{FF02::1:FF04:0506}}};
\draw [->] (LL) -- (MS1);
\draw [->] (GP) -- (MS1);

\draw (7.4, 1.75) node (MS2) [right, draw, shade, top color = red!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{FF02::1:FF00:0001}}};
\draw [->] (manuel) -- (MS2);

\draw (2.5, 0.75) node (mac2) [right, draw, shade, top color = blue!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{33-33-FF-04-05-06}}};
\draw [->] (MS1) -- (mac2);

\draw (7.4, 0.75) node (mac3) [right, draw, shade, top color = blue!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{33-33-FF-00-00-01}}};
\draw [->] (MS2) -- (mac3);
</tikz>

La figure Construction de l'adresse de Multicast sollicité montre comment l'on passe d'une adresse IPv6 unicast à une adresse de multicast sollicité. Il s'agit de prendre les 3 derniers octets de l'adresse unicast que l'on concatène avec le préfixe IPv6 multicast <tt>FF02::1:FF00:0/104</tt>.

Dans l'exemple, les deux adresses dérivant d'une adresse MAC conduisent à la même adresse de multicast sollicité, tandis que la configuration manuelle d'une interface conduit à la construction d'une autre adresse de multicast sollicité. On peut noter que le risque que deux machines sur un lien aient la même adresse de multicast sollicité est très faible. Pour celles dérivant d'une adresse MAC, il faudrait que les 3 derniers octets soient identiques, ce qui est impossible chez un même constructeur et la probabilité d'avoir, sur un même lien, des cartes de deux constructeurs différents se terminant par les mêmes 3 derniers octets est très faible. Pour la numérotation manuelle des interfaces, une machine ayant l'adresse <tt>GP:::0100:0001</tt> conduirait à construire la même adresse de multicast sollicité <tt>FF02::1:FF00:0001</tt>, mais cette numérotation manuelle des interfaces n'est pas logique.

{{HorsTexte|Sollicitation des voisins|L'algorithme de découverte des adresses de niveau 3 des voisins (inclus dans Neighbor Discovery) fonctionne de la manière suivante. La machine qui recherche un voisin dont elle connait l'adresse IPv6, effectue l'algorithme décrit précédemment. Elle émet la requête en utilisant l'adresse MAC obtenue. Seule la machine qui possède cette adresse est abonnée à ce groupe, elle sera donc la seule à traiter la requête et à y répondre.}}

L'exemple se poursuit par la transformation de l'adresse de Multicast au niveau IPv6 en adresse de multicast de niveau 2. Elle est très spécifique à la technologie et à la manière dont est mis en œuvre le multicast au niveau 2. Pour les réseaux Ethernet (et dérivés comme le Wi-Fi), les 4 derniers octets de l'adresse multicast sollicité sont ajoutés au préfixe <tt>33-33</tt>.
{{Suivi| Introduction|Introduction | AdressageBis-MeO|Mises en Oeuvre}}

AdressageBis-Fondamentaux

2011-12-25T15:39:57Z

Ltoutain: /* Représentation des adresses */

{{Suivi| Introduction|Introduction | AdressageBis-MeO|Mises en Oeuvre}}

Le format et la représentation des adresses sont les modifications les plus visibles pour l'utilisateur expérimenté et l'ingénieur réseau dans cette nouvelle version du protocole. En effet la taille de l'adresse reste fixe mais passe de 32 à 128 bits. Même si les principes sont fortement similaires à ceux employés dans IPv4, cet adressage apparaît à première vue beaucoup plus complexe. Il est intéressant d'en comprendre le principe et les règles d'attribution avant d'aborder les aspects protocolaires.

Ce chapitre présente les différents types d'adresses. Il explique en détail le plan d'adressage agrégé qui a été retenu pour construire l'Internet IPv6. Il décrit également la manière de constituer une adresse IPv6.

= Aspects fondamentaux de l'adressage IPv6=

==<div id="representation">Représentation des adresses ==

La représentation textuelle d'une adresse IPv6 se fait en découpant le mot de 128 bits de l'adresse en 8 mots de 16 bits séparés par le caractère «:», chacun d'eux étant représenté en hexadécimal. Par exemple :

<tt>2001:0DB8:0000:0000:0400:A987:6543:210F</tt>

Dans un champ, il n'est pas nécessaire d'écrire les zéros placés en tête :

<tt>2001:DB8:0:0:400:A987:6543:210F</tt>

En outre plusieurs champs nuls consécutifs peuvent être abrégés par «::». Ainsi l'adresse précédente peut s'écrire comme suit :

<tt>2001:DB8::400:A987:6543:210F</tt>

Naturellement, pour éviter toute ambiguïté, l'abréviation «::» ne peut apparaître qu'une fois au plus dans une adresse. Les cas extrêmes sont l'adresse indéfinie (utilisée pour désigner les routes par défaut) à tous les bits à zéro et qui se note de manière compacte :

<tt>::</tt>

et l'adresse de bouclage (loopback), équivalent du préfixe <tt>127/8</tt> dont tous les bits sont à zéro sauf le dernier et qui s'écrit :

<tt>::1</tt>

La représentation des préfixes réseau IPv6 est similaire à la notation CIDR RFC 1519 utilisée pour les préfixes IPv4. Un préfixe IPv6 est donc représenté par la notation :

adresse-ipv6/longueur-du-préfixe-en-bits

Les formes abrégées avec «::» sont autorisées.

<tt>2001:0DB8:7654:3210:0000:0000:0000:0000/64
2001:DB8:7654:3210:0:0:0:0/64
2001:DB8:7654:3210::/64</tt>

Le seul piège de cette notation vient des longueurs de préfixes qui ne sont pas en frontière de «:». Ainsi le préfixe <tt>3EDC:BA98:7654:3::/56</tt> équivaut en réalité à <tt>3EDC:BA98:7654:0000::/56</tt> car il s'écrit <tt>3EDC:BA98:7654:0003::/56</tt>.

On peut combiner le préfixe réseau avec l'identifiant de l'interface en une seule notation. Ainsi cette adresse IPV6
<tt>2001:DB8:7654:3210:945:1321:ABA8:F4E2/64</tt>
indique que le préfixe réseau est constitué par les 64 premiers bits.

{{HorsTexte|Apprendre à gaspiller|Du fait de sa longueur, une règle de bonne gestion consiste à relâcher les contraintes sur les longueurs de préfixe. Ainsi en utilisant quand cela est possible des multiples de 4 permet d'avoir un préfixe qui tient sur un caractère affiché. Dans l'exemple suivant 47 n'étant pas un multiple de 4, <tt>2001:DB0:1234::/47</tt> représente les préfixes commençant par <tt>2001:DB0:1234</tt> et <tt>2001:DB0:1235</tt>}}

Ces représentations peuvent apparaître beaucoup plus complexes qu'avec IPv4, mais en vérité des adresses logiques ou concises peuvent être constituées au moyen de règles strictes. Ces règles favorisent grandement la manipulation et la mémorisation des adresses comme nous verrons par la suite (cf Adressage global)

Dans certains cas, une adresse (voire plusieurs adresses) IPv4 peut être contenue dans une adresse IPv6. Pour les faire ressortir, la notation classique d'IPv4, c'est à dire 4 octets en représentation décimale séparés par des points, peut être utilisée au sein d'une adresse IPv6. Ainsi :

<tt>::128.12.13.14</tt>

représente une adresse IPv6 composée de 96 bits à 0 suivis des 32 bits de l'adresse IPv4 <tt>128.12.13.14</tt>

Il est pourtant parfois nécessaire de manipuler littéralement des adresses IPv6. Le caractère ":" utilisé pour séparer les mots peut créer des ambiguïtés. C'est le cas avec les URL où il est aussi utilisé pour indiquer le numéro de port. Ainsi l'URL

<tt><nowiki>http://2001:DB8:12::1:8000/</nowiki></tt>

peut aussi bien indiquer le port 8000 sur la machine ayant l'adresse IPv6 2001:DB8:12::1, que la machine 2001:DB8:12::1:8000 en utilisant le port par défaut. Pour lever cette ambiguïté, le RFC 2732 propose d'inclure l'adresse IPv6 entre "[ ]". L'adresse précédente s'écrirait :

<tt><nowiki>http://[2001:DB8:12::1]:8000/</nowiki></tt>

ou

<tt><nowiki>http://[2001:DB8:12::1:8000]/</nowiki></tt>

suivant les cas. Cette représentation peut être étendue à d'autres domaines comme X-window ou au protocole de signalisation téléphonique SIP.

== Type des adresses ==

IPv6 reconnaît trois types d'adresses : unicast, multicast et anycast. Le type d'adresse définit la cardinalité de la communication: à combien de destinataire doit être remis le paquet.

Le premier de ces types désigne de manière unique une interface. Un paquet envoyé à une telle adresse, sera donc remis à l'interface ainsi identifiée. Parmi les adresses unicast, on peut distinguer celles qui auront une portée globale, c'est-à-dire désignant sans ambiguïté une destination sur le réseau Internet et celles qui auront une portée locale (lien ou site). Ces dernières ne pourront pas être routées sur l'Internet c'est à dire qu'un paquet comportant une adresse de destination avec une portée locale sera ignoré et éliminé par un routeur de l'Internet. La portée d'une adresse indique en faite la limite de la propriété d'unicité.

Une adresse de type multicast désigne un groupe d'interfaces qui en général appartiennent à des noeuds différents pouvant être situés n'importe où dans l'Internet. Lorsqu'un paquet a pour destination une adresse de type multicast, il est acheminé par le réseau à toutes les interfaces membres de ce groupe.

Il faut noter qu'il n'y a plus d'adresses de type broadcast comme sous IPv4 ; elles sont remplacées par des adresses de type multicast. En effet, l'adresse de broadcast peut être émulée avec une adresse multicast en constituant un groupe qui comporte tous les noeuds. De plus, l'absence de broadcast évite les problèmes de saturation des réseaux locaux commutés. Ainsi un réseau IPV6 passe mieux en terme de facteur d'échelle sur ce type de réseau.

Le dernier type, anycast, est une officialisation de propositions faites pour IPv4 RFC 1546. Comme dans le cas du multicast, une adresse de type anycast désigne un groupe d'interfaces, la différence étant que lorsqu'un paquet a pour destination une telle adresse, il est acheminé à un des éléments du groupe et non pas à tous. C'est, par exemple, le plus proche au sens de la métrique des protocoles de routage. Cet adressage est principalement expérimental, voir [[Anycast|Adresses anycast]].

Certains types d'adresses sont caractérisés par leur préfixe RFC 3513. Le tableau suivant (source : http://www.iana.org/assignments/ipv6-address-space) donne la liste de ces préfixes. La plage «réservée» du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70% de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.

{|
!Préfixe IPv6!!Allouer!!Référence
|-style="background:silver"
|<tt>0000::/8</tt>||[[Autres types d'adresses|Réservé pour la transition et loopback]]||RFC 3513
|-
|<tt>0100::/8</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>0200::/7</tt>||Réservé (ex [[Autres types d'adresses#Les adresses NSAP|NSAP]])||RFC 4048
|-
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 3513
|-style="background:silver"
|<tt>0800::/5</tt>||Réservé||RFC 3513
|-
|<tt>1000::/4</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>2000::/3</tt>||[[Unicast Global]]||RFC 3513
|-
|<tt>4000::/3</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>6000::/3</tt>||Réservé||RFC 3513
|-
|<tt>8000::/3</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>A000::/3</tt>||Réservé||RFC 3513
|-
|<tt>C000::/3</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>E000::/4</tt>||Réservé||RFC 3513
|-
|<tt>F000::/5</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>F800::/6</tt>||Réservé||RFC 3513
|-
|<tt>FC00::/7</tt>||[[Site-local#ula|Unique Local Unicast]]||RFC 4193
|-style="background:silver"
|<tt>FE00::/9</tt> ||Réservé||RFC 3513
|-
|<tt>FE80::/10</tt>||[[Lien-local]]||RFC 3513
|-style="background:silver"
|<tt>FEC0::/10</tt>||Réservé||RFC 3879
|-
|<tt>FF00::/8</tt>||Multicast||RFC 3513
|}

Une interface possèdera généralement plusieurs adresses IPv6. En IPv4 ce comportement est exceptionnel, il est banalisé en IPv6.

= Adressage global : plan d'adressage agrégé =

Ce plan, proposée dans le RFC 3587, précise la structure d'adressage IPv6 définie dans le RFC 3513 en précisant les tailles de chacun des blocs. Il est géré de la même manière que CIDR en IPv4. Une adresse intègre trois niveaux de hiérarchie :

<tikz title="Adresses Globales">
\clip (0.0, 0) rectangle (11.5,7);
% \draw[help lines] (0,0) grid (10,6);

% \draw (0, 6.6) node [right] {Global Unicast Address:};

\draw (0,5) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tt{001}};
\draw (1,5) node [right, draw, shade, top color = green, minimum width=3cm, minimum height=1cm] {Global Prefix};
\draw (4,5) node [right, draw, shade, top color = blue, minimum width=1.5cm, minimum height=1cm] {SID};
\draw (5.5,5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.5, 5.7) node {\tiny{3}};
\draw (2.5, 5.7) node {\tiny{45}};
\draw (4.7, 5.7) node {\tiny{16}};
\draw (8, 5.7) node {\tiny{64}};

\draw [snake=brace, mirror snake] (0, 4.20) -- (4, 4.20) node [below, midway] {\tiny{
\ifthenelse{\equal{francais}{true}}{Topologie Publique}{public topology}}
} node [below = 8pt, midway] {\tiny{given by the provider}} ;
\draw [snake=brace, mirror snake] (4, 4.20) -- (5.5, 4.20) node [below, midway] {\tiny{local topology}} node [below = 8pt, midway] {\tiny{assigned by network engineer}} ;
\draw [snake=brace, mirror snake] (5.5, 4.20) -- (10.3, 4.20) node [below, midway] {\tiny{link address}} node [below = 8pt, midway] {\tiny{auto or manual configuration}} ;
</tikz>

* une topologie publique (appelée '''Global Prefix''') codée sur 48 bits, allouée par le fournisseur d'accès;
* une topologie de site codée sur 16 bits (appelée '''Subnet ID'''). Ce champ permet de coder les numéros de sous réseau du site;
* un [[identifiant d'interface]] sur 64 bits (appelé '''Interface ID''') distinguant les différentes machines sur le lien.

==Structuration du prefixe global (GP)==

{{HorsTexte|Appréhender les tailles|France Télécom a obtenu du RIPE-NCC un <tt>/19</tt>. Si l'on enlève les troix premiers bits <tt>001</tt> désignant le plan d'adressage, il est donc possible d'avoir 216 opérateurs. Sachant qu'il y a 192 pays à l'ONU, ils pourraient chacun abriter 320 opérateurs de la taille de FT, chacun pouvant attribuer jusqu'à 229 <tt>/48</tt>, soit 536 870 912 sites}}

A part le préfixe <tt>2002::</tt> qui est est réservé au mécanisme de transition [[6to4]], cet espace est géré hierarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales ([http://www.iana.org/numbers/ RIR]) des préfixes actuellement de longueur 12 (cf. http://www.iana.org/assignments/ipv6-unicast-address-assignments) qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long. Le site http://www.sixxs.net/tools/grh/ donne en temps réel les allocations de préfixes par région, opérateur et pays.

Il est maintenant admis que le préfixe attribué par un opérateur à ses clients peut également être un <tt>/56</tt>. En effet, si l'on garde l'attribution de préfixe de longueur 48 pour les sites terminaux, et que l'on intègre les réseaux domotiques, les opérateurs peuvent justifier d'un besoin important d'adresses que les autorités régionales ne peuvent leur refuser.

{{ToDo|Ajouter comment obtenir un préfixe auprès de RIPE-NCC}}

==Structuration de l'identifiant de sous-réseau (SID)==

Il n'existe pas de règles pour allouer les identificateurs de sous-réseau au sein d'un site. Plusieurs techniques (non exclusives) peuvent être utilisées :

* numéroter de manière incrémentale les sous-réseaux: 0001, 0002, ... Cette technique est simple a mettre en œuvre dans des réseaux expérimentaux, mais elle peut conduire à un plan d'adressage à plat difficile à mémoriser. Elle peut être utilisée par exemple pour un sous-réseau dédié aux serveurs pour simplifier l'écriture et la mémorisation des adresses.
* utiliser le numéro de VLAN. Elle permet d'éviter de mémoriser plusieurs niveaux de numérotation.
* séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau suivant contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs :

{|
!Communauté !! 4bits !! width="50%"|8bits !! 4bits
|-style="background:silver"
| Infrastructure || 0 || colspan=2 | valeurs spécifiques
|-
| Tests || 1 || colspan=2 | valeurs spécifiques
|-style="background:silver"
| Tunnels || 6 || colspan=2 | allocation de /60 aux utilisateurs
|-
| Invités Wi-Fi || 8 || colspan=2 | valeurs spécifiques
|-style="background:silver"
| Personnels || A || Entité || Sous-Réseaux
|-
| Etudiants || E || Entité || Sous-Réseaux
|-style="background:silver"
| Autres (Start up, etc.) || F || colspan=2 | valeurs spécifiques
|+ Affectation des SID dans une université
|}

Ainsi, le préfixe:
* <tt>2001:DB8:1234::/52</tt> servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs seront prises dans cet espace;
* <tt>2001:DB8:1234:8000::/52</tt> servira pour le réseau Wi-Fi des invités. La manière dont sont gérés les 12 bits restants du SID ne sont pas spécifiés;
* <tt>2001:DB8:1234:E000::/52</tt> servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.

=== Adressage local : adresses lien-local ===

Les adresses de type lien-local (''link local use address'') sont des adresses dont la validité est restreinte à un lien, c'est-à-dire l'ensemble de interfaces directement connectées sans routeur intermédiaire comme par exemple des machines branchées sur un même réseau Ethernet, des machines reliées par une connexion PPP, ou des extrémités d'un tunnel. Les adresses lien-local sont configurées automatiquement à l'initialisation de l'interface et permettent la communication entre nœuds voisins. L'adresse est obtenue en concaténant le préfixe <tt>FE80::/64</tt> aux 64 bits de l'[[Identifiant d'interface|identifiant d'interface]]. L'identifiant d'interface est généralement basé sur l'adresse MAC. Cela ne pose pas de problème de respect de le vie privée car, contrairement aux adresses globales, les adresses lien-local ne sortent jamais du réseau où elles sont utilisées.

<tikz title="Adresses Lien-local">
% \draw (0, 3) node [right] {Link-Local Address:};
\draw (0,1.5) node [right, draw, shade, top color = yellow, minimum width=1.5cm, minimum height=1cm] {FE80};
\draw (1.5,1.5) node [right, draw, minimum width=4cm, minimum height=1cm] {0...0};
\draw (5.5,1.5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.7, 2.2) node {\tiny{10}};
\draw (3.5, 2.2) node {\tiny{54}};
\draw (8, 2.2) node {\tiny{64}};

\draw [snake=brace, mirror snake] (5.5, 0.8) -- (10.3, 0.8) node [below, midway] {\tiny{link address}} node [below = 8pt, midway] {\tiny{auto-configuration}} ;
</tikz>

Ces adresses sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins (''neighbor discovery'') et de découverte de routeurs (''router discovery''). Ce sont de nouveaux dispositifs, le premier supplantant en particulier le protocole ARP (''Address Resolution Protocol''), qui permettent à un réseau local de se configurer automatiquement (voir [[Découverte de voisins]]). Elles sont également largement utilisées par les protocoles de routage soit pour l'échange de données (cf. RIPng, OSPFv3), soit dans les tables de routage puisque le champ ''prochain routeur'' est toujours un équipement directement accessible sur le lien.
{{HorsTexte|Unicité sur le lien|Les adresses lien-local sont uniques à l'intérieur d'un lien. Le protocole de détection de duplication d'adresses (voir [[Configuration automatique#DAD|Détection d'adresse dupliquée]]) permet de s'en assurer. Par contre la duplication d'une adresse lien-local entre deux liens différents, ou entre deux interfaces d'un même nœud est autorisée.}}

Un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type lien-local.

Le fait que ces adresses aient une portée très faible les limite dans la pratique au cas où un démarrage automatique (''bootstrap'') est nécessaire. Leur usage ne doit pas être généralisé dans les applications classiques en régime stabilisé.

==== Portée de l'adresse (''scoped address'') ====

Une adresse lien-local (ou multicast) n'indique pas intrinsèquement l'interface de sortie, puisque toutes les interfaces partagent le même préfixe <tt>fe80::/10</tt>. Il faut donc indiquer de manière explicite sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère "%". Sous Linux, un argument, généralement <tt>-I</tt> permet de la désigner.

===Unique Local Address===

Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local Address''). Ces adresses sont destinées à une utilisation locale. Elles ne sont pas définies pour être routées dans l'Internet, mais seulement au sein d'une zone limitée telle qu'un site ou entre un nombre limité de sites. Les adresses uniques locales ont les caractéristiques suivantes :

* Prefixe ''globalement'' unique;
* Préfixe clairement défini facilitant le filtrage sur les routeurs de bordure;
* Permet l'interconnexion de sites sans générer de conflit d'adresse et sans nécessiter de renumérotation;
* Indépendantes des fournisseurs d'accès à l'Internet et ne nécessitent donc pas de connectivité;
* Pas de conflit en cas de routage par erreur en dehors d'un site;
* Aucune différence pour les applications, qui peuvent les considérer comme des adresses globales unicast standard.

<tikz title="Unique Local Addresses">
\clip (0, 0) rectangle (11,4);
% \draw[help lines] (0,0) grid (10,3);

% \draw (0, 3.6) node [right] {Unique Local IPv6 Unicast Addresses:};

\draw (0,2) node [right, draw, shade, top color = yellow, minimum width=1.5cm, minimum height=1cm] {FD};
\draw (1.5,2) node [right, draw, shade, top color = green, minimum width=3cm, minimum height=1cm] {Random Value};
\draw (4.5,2) node [right, draw, shade, top color = blue, minimum width=1cm, minimum height=1cm] {SID};
\draw (5.5,2) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.7, 2.7) node {\tiny{8}};
\draw (2.7, 2.7) node {\tiny{40}};
\draw (4.7, 2.7) node {\tiny{16}};
\draw (8, 2.7) node {\tiny{64}};

\draw [snake=brace, mirror snake] (0, 1.20) -- (4.5, 1.20) node [below, midway] {\tiny{private topology}} node [below = 8pt, midway] {\tiny{Not Routable in the Internet}} ;
\draw [snake=brace, mirror snake] (4.5, 1.20) -- (5.5, 1.20) node [below, midway] {\tiny{local topology}};
\draw [snake=brace, mirror snake] (5.5, 1.20) -- (10.3, 1.20) node [below, midway] {\tiny{link address}} ;
</tikz>

Les adresses uniques locales sont créées en utilisant un identifiant global (''Global ID'') généré pseudo-aléatoirement. Ces adresses suivent le format suivant :

* <tt>Prefix</tt> (7 bits) : <tt>FC00::/7</tt> préfixe identifiant les adresses IPv6 locales (''ULA'')
* <tt>L</tt> (1 bit) : Positionné à 1, le préfixe est assigné localement. La valeur 0 est réservée pour une utilisation future.
* <tt>Global ID</tt> (40 bits) : Identifiant global utilisé pour la création d'un préfixe ''unique'' (''Globally Unique Prefix'').
* <tt>Subnet ID</tt> (16 bits) : Identifiant d'un sous réseau à l'intérieur du site.
* <tt>Interface ID</tt> (64 bits) : L'indentifiant d'interface tel que défini dans [[Identifiant d'interface]].

Le site http://www.sixxs.net/tools/grh/ula/ permet de créer et d'enregistrer son adresse ULA à partir d'une adresse MAC.

= Structuration de l'identifiant d'interface (IID) =

Si initialement pour des raisons d'auto-configuration, l'identifiant d'interface devait toujours être dérivé de l'adresse de niveau 2, c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits:

* manuelle,
* basée sur l'adresse de niveau 2 de l'interface,
* aléatoire,
* cryptographique.

== Manuel ==
{{HorsTexte|Le resolveur DNS|Le résolveur DNS est le cas le plus flagrant; chaque machine sur le réseau doit être configurée avec l'adresse IPv6 du serveur DNS. En cas de changement de carte réseau, l'ensemble des machines du domaine devront être reconfigurées. Si l'on ne souhaite pas utiliser des protocoles de configuration automatique de type DHCPv6, il est préférable d'attribuer au résolveur DNS une adresse manuelle.}}
Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces, car dans ce cas l'adresse IPv6 est facilement mémorisable, et le serveur peut être accessible même si le DNS n'est pas actif.
Il existe plusieurs techniques plus ou moins mnémotechniques :
* incrémenter l'identifiant d'interface à chaque nouveau serveur créé

<tt>2001:DB8:1234:1::1</tt>
<tt>2001:DB8:1234:1::2</tt>
...

* reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple si un serveur a comme adresse IPv4 <tt>192.0.2.123</tt>, son adresse IPv6 sera :

<tt>2001:DB8:1234:1::7B</tt>
ou plus simplement
<tt>2001:DB8:1234:1::123</tt>

* reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à taper :

<tt>2001:DB8:1234:1::192.0.2.123</tt>

== Dérivé de l'adresse de l'interface==

L'avantage d'utiliser une adresse de niveau 2 pour construire un identifiant d'interface est que l'unicité de cette valeur est presque toujours assurée. En plus, cette valeur est stable tant que la carte réseau de la machine n'est pas changée. Par contre, ces valeurs sont difficilement mémorisables.

Les adresses lien-local sont construites en utilisant ce type d'identifiant. Par contre pour les adresses globales, il est conseillé de ne les utiliser que pour les machines client et de préférer les identifiants d'interface manuels pour les serveurs.

Ces identifiants d'interface étant stables dans le temps, à chaque fois qu'un individu change de réseau, il change de préfixe, mais garde le même identifiant d'interface. Ce dernier pourrait donc servir à tracer les déplacements d'un individu. Le risque est faible, car les cookies mis en place par les serveurs web sont bien plus efficaces, mais ils ne s'agit plus d'un problème réseau. Autre désavantage, comme les adresses MAC contiennent l'identification du matériel, il est possible d'indiquer à l'exterieur du réseau quel type de materiel est utilisé et donner des indications.

Si ces inconvénients sont jugés importants par l'entreprise, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement.

=== EUI-64 ===

<tikz title="Transformation d'une adresse MAC en identifiant d'interface">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{u}g}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (5, 1.5) node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};

</tikz>

L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (firewire) ou IEEE 802.15.4 (réseau de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64.

Il existe plusieurs méthodes pour construire l'identifiant :
{{HorsTexte|Ordre de transmission|L'ordre des bits ne doit pas porter à confusion. Dans la représentation numérique des valeurs, le premier bit transmis est le bit de poids faible, c'est-à-dire le bit de droite. Ainsi sur le support physique le bit <tt>g</tt>, puis le bit <tt>u</tt> puis les bits suivants sont transmis. }}

* Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure décrite figure Identificateur global IEEE EUI-64.
: Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802, identifient le constructeur et les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits <tt>u</tt> (septième bit du premier octet) et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :
:* <tt>u</tt> (Universel) vaut <tt>0</tt> si l'identifiant EUI-64 est universel,
:* <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g = 0</tt>), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g = 1</tt>), par exemple une adresse de multicast.

<tikz title="Identificateur d'interface dérivé d'une EUI-64">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (5, 1.5) node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};

</tikz>
* L'identifiant d'interface à 64 bits est dérivé de l'EUI-64 en inversant le bit <tt>u</tt> (cf. figure Identificateur d'interface dérivé d'une EUI-64). En effet, pour la construction des adresses IPv6, on a préféré utiliser <tt>1</tt> pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur <tt>0</tt> pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de <tt>1</tt>.

===MAC-48===

<tikz title="Transformation d'une adresse MAC en identifiant d'interface">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\only<2-> {
\draw (3, 4.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
\draw (4, 4.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (3, 4.25) rectangle+(3, 0.5);

\draw (0,4.5) node [right] {MAC-48};

\draw (6, 4.5) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (2, 3) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
\draw (3, 3) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 2.75) rectangle+(3, 0.5);

\draw (7, 3) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (6,4.5) -- (6, 4) -- (5, 3.5) -- (5, 3);
\draw (6,4) -- (7, 3.5) -- (7, 3);
\draw (3, 4.5) -- (3, 4) -- (2, 3.5) -- (2, 3);
\draw (9, 4.5) -- (9, 4) -- (10, 3.5) -- (10, 3);

\draw (5, 3) node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};

\draw (0,3) node [right] {EUI-64};
}

\only<3-> {

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (7, 1.5) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (5, 1.5) node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};

\draw (2,3) -- (2, 1.5);
\draw (10,3) -- (10, 1.5);
\draw (0,1.5) node [right] {IID};
}

</tikz>

* Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi). L'adresse est tout d'abord convertie en EUI-64, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure ci-contre illustre ce processus.

===Cas Particuliers===
* Si une interface possède une adresse locale unique sur le lien, mais non universelle (par exemple le format d'adresse IEEE 802 sur 2 octets ou une adresse sur un réseau Appletalk), l'identifiant d'interface est construit à partir de cette adresse en rajoutant des 0 en tête pour atteindre 64 bits.

{{HorsTexte|Erreur de l'IETF|À noter que l'IETF s'est trompée quand elle a défini l'algorithme de conversion. En effet, l'ajout de la valeur <tt>0xFFFE</tt> concerne les EUI-48, c'est-à-dire des identifiants, alors qu'Ethernet utilise des MAC-48, c'est-à-dire des adresses (ils servent à transporter des trames vers le bon destinataire). La bonne valeur aurait été <tt>0xFFFF</tt>. Mais cette erreur n'a aucune conséquence pour l'identification des équipements, elle n'a donc pas été corrigée par la suite.}}

* Si une interface ne possède aucune adresse (par exemple l'interface utilisée pour les liaisons PPP), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle ou bien une génération aléatoire, avec le bit u positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, et devra être résolu manuellement.

== Valeur aléatoire ==

L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pourrait poser des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur, qui même s'il se déplace de réseau en réseau garde ce même identifiant. Il serait alors possible de traquer un individu utilisant un portable, chez lui, au bureau, lors de ses déplacements. Ce problème est similaire à l'identificateur placé dans les processeurs Pentium III.

[[image:Windows7-IIDalea.png|500px|right]]

Pour couper court à toute menace de boycott d'un protocole qui « menacerait la vie privée », il a été proposé d'autres algorithmes de construction d'un identifiant d'interface basé sur des tirages aléatoires (voir RFC 3041). Un utilisateur particulièrement méfiant pourrait valider ces mécanismes. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme comme MD5 à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.

Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globale. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (i.e. les applications serveur). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours et sert aux applications client. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur Linux et les système d'exploitation BSD comme Mac OS.

Bien entendu pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse ou que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit impossible.

En contre partie, il est plus difficile à un administrateur réseau de filtrer les machines puisque celles-ci changent périodiquement d'adresses.

== Cryptographique ==

{{HorsTexte|Encore un sujet de recherche|L'usage de ces adresses n'est pas encore généralisé. Shim6 pour la gestion de la multi-domiciliation ou SEND pour sécuriser la découverte de voisins y ont recours.}}
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.

=Adresses Multicast=
{{HorsTexte|Portée et portée|Il ne faut pas confondre la portée d'une adresse link-local ou multicast qui désigne l'interface par laquelle sera émis le paquet et la portée d'un groupe multicast qui désigné l'étendue de la couverture}}
Cette section décrit brièvement le système d'adressage multicast IPv6 et ne s'intéresse qu'aux adresses utilisées localement par les protocoles directement liés à IPv6 (Découverte de voisins, DHCPv6,...). Pour plus de détails sur le multicast en général, se reporter au chapitre [[Multicast]]. La figure Structure de l'adresse IPv6 Multicast donne le format de l'adresse IPv6 de multicast décrite dans le RFC 3513.

<tikz title="Structure de l'adresse IPv6 Multicast">
\clip (0, 1) rectangle (11,4);
% \draw[help lines] (0,0) grid (10,4 );

% \draw (0, 3.6) node [right] {Generic Format:};

\draw (0,2) node [right, draw, shade, top color = yellow, minimum width=2cm, minimum height=1cm] {FF};
\draw (2,2) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tiny{\tt{xRPT}}};
\draw (3,2) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tiny{scope}};
\draw (4,2) node [right, draw, shade, top color = black!50, minimum width=6cm, minimum height=1cm] {Group ID};

\draw (1, 2.7) node {\tiny{8}};
\draw (2.5, 2.7) node {\tiny{4}};
\draw (3.5, 2.7) node {\tiny{4}};
\draw (7, 2.7) node {\tiny{112}};

</tikz>

Les adresses multicast IPv6 sont dérivées du préfixe <tt>FF00::/8</tt>. Le champ drapeaux de 4 bits est défini de la manière suivante :

* Seul le bit <tt>T</tt> (comme ''Transient'') du champ drapeaux est initialement décrit dans le RFC 3513. La valeur <tt>0</tt> indique une adresse multicast bien connue gérée par une autorité. La valeur <tt>1</tt> indique une valeur temporaire.
* Les bits <tt>P</tt> et <tt>R</tt> sont décrits dans le RFC 3306 et le draft Internet sur embedded-RP (RFC 3956).
* Le bit de poids fort du champ drapeaux n'est pas encore attribué.

Le champ drapeaux permet de définir plusieurs types d'adresses multicast IPv6 qui seront décrits dans les sections suivantes.

Le champ scope de l'adresse multicast IPv6 permet d'en limiter la portée (''scope'' en anglais). En IPv4, la portée d'un paquet est limitée par le champ TTL (''Time To Live''), de même des préfixes peuvent être définis pour identifier des adresses à portée réduite. Les valeurs suivantes sont définies dans la RFC 2373 :

* 1 - node-local : Les paquets ne sortent pas de la machine, cette adresse sert pour la communication entre les applications.
* 2 - link-local : La portée se limite au réseau local, les paquets ne peuvent pas traverser les routeurs multicast. Cette valeur est utilisée en particulier par le protocole de découverte des voisins.
* 3 - subnet-local : Ce type n'est pas officiellement défini, mais se retrouve dans certains documents. Il permet de faire la différence entre un lien physique et un lien logique (regroupement de plusieurs liens physiques) partageant le même préfixe IPv6.
* 4 - admin-local
* 5 - site-local
* 8 - organisation-local
* E - global
* Les portées 0 et F sont réservées.

http://www.iana.org/assignments/ipv6-multicast-addresses donne les adresses multicast définies. Le tableau ci-dessous liste les plus utilisées :

{|
!Adresse multicast !! usage
|-style="background:silver"
| FF01::1 || All Nodes Address
|-
| FF01::2 || All Routers Address
|-style="background:silver"
| FF02::1 || All Nodes Address
|-
| FF02::2 || All Routers Address
|-style="background:silver"
| FF02::5 || OSPFIGP
|-
| FF02::6 || OSPFIGP Designated Routers
|-style="background:silver"
| FF02::9 || RIP Routers
|-
| FF02::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-style="background:silver"
| FF02::1:2 || All-dhcp-agents
|-
| FF03::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-style="background:silver"
| FF04::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-
| FF05::2 || All Routers Address
|-style="background:silver"
| FF05::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-
| FF05::1:3 || All-dhcp-servers
|-style="background:silver"
| FF0X::101 || Network Time Protocol (NTP)
|}

==Adressage Multicast Sollicité==

IPv6 interdit l'utilisation de la diffusion généralisée (Broadcast) lorsque le Multicast est disponible. Ainsi les protocoles comme Neighbor Discovery, chargé de faire le lien entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse de Multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>FF02::1</tt> (tous les équipements sur le lien, l'utilisation des adresses de multicast sollicité permet de réduire considérablement le nombre d'équipements qui recevront la requête.

<tikz title="Construction de l'adresse de Multicast sollicité">
\clip (0, 0) rectangle (10,4);
%\draw[help lines] (0,0) grid (10,4 );

\draw (2, 3.75) node (mac) [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{01-02-03-04-05-06}}};

\draw (0, 2.75) node (LL) [right, draw, shade, top color = green!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{FE80::0102:03FF:FE04:0506}}};

\draw (4, 2.75) node (GP) [right, draw, shade, top color = green!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{GP:0102:03FF:FE04:0506}}};

\draw [->] (mac) -- (LL);
\draw [->] (mac) -- (GP);

\draw (8, 2.75) node (manuel) [right, draw, shade, top color = green!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{GP::1}}};

\draw (2.5, 1.75) node (MS1) [right, draw, shade, top color = red!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{FF02::1:FF04:0506}}};
\draw [->] (LL) -- (MS1);
\draw [->] (GP) -- (MS1);

\draw (7.4, 1.75) node (MS2) [right, draw, shade, top color = red!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{FF02::1:FF00:0001}}};
\draw [->] (manuel) -- (MS2);

\draw (2.5, 0.75) node (mac2) [right, draw, shade, top color = blue!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{33-33-FF-04-05-06}}};
\draw [->] (MS1) -- (mac2);

\draw (7.4, 0.75) node (mac3) [right, draw, shade, top color = blue!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{33-33-FF-00-00-01}}};
\draw [->] (MS2) -- (mac3);
</tikz>

La figure Construction de l'adresse de Multicast sollicité montre comment l'on passe d'une adresse IPv6 unicast à une adresse de multicast sollicité. Il s'agit de prendre les 3 derniers octets de l'adresse unicast que l'on concatène avec le préfixe IPv6 multicast <tt>FF02::1:FF00:0/104</tt>.

Dans l'exemple, les deux adresses dérivant d'une adresse MAC conduisent à la même adresse de multicast sollicité, tandis que la configuration manuelle d'une interface conduit à la construction d'une autre adresse de multicast sollicité. On peut noter que le risque que deux machines sur un lien aient la même adresse de multicast sollicité est très faible. Pour celles dérivant d'une adresse MAC, il faudrait que les 3 derniers octets soient identiques, ce qui est impossible chez un même constructeur et la probabilité d'avoir, sur un même lien, des cartes de deux constructeurs différents se terminant par les mêmes 3 derniers octets est très faible. Pour la numérotation manuelle des interfaces, une machine ayant l'adresse <tt>GP:::0100:0001</tt> conduirait à construire la même adresse de multicast sollicité <tt>FF02::1:FF00:0001</tt>, mais cette numérotation manuelle des interfaces n'est pas logique.

{{HorsTexte|Sollicitation des voisins|L'algorithme de découverte des adresses de niveau 3 des voisins (inclus dans Neighbor Discovery) fonctionne de la manière suivante. La machine qui recherche un voisin dont elle connait l'adresse IPv6, effectue l'algorithme décrit précédemment. Elle émet la requête en utilisant l'adresse MAC obtenue. Seule la machine qui possède cette adresse est abonnée à ce groupe, elle sera donc la seule à traiter la requête et à y répondre.}}

L'exemple se poursuit par la transformation de l'adresse de Multicast au niveau IPv6 en adresse de multicast de niveau 2. Elle est très spécifique à la technologie et à la manière dont est mis en œuvre le multicast au niveau 2. Pour les réseaux Ethernet (et dérivés comme le Wi-Fi), les 4 derniers octets de l'adresse multicast sollicité sont ajoutés au préfixe <tt>33-33</tt>.
{{Suivi| Introduction|Introduction | AdressageBis-MeO|Mises en Oeuvre}}

AdressageBis-Fondamentaux

2011-12-25T15:39:21Z

Ltoutain: /* Représentation des adresses */

{{Suivi| Introduction|Introduction | AdressageBis-MeO|Mises en Oeuvre}}

Le format et la représentation des adresses sont les modifications les plus visibles pour l'utilisateur expérimenté et l'ingénieur réseau dans cette nouvelle version du protocole. En effet la taille de l'adresse reste fixe mais passe de 32 à 128 bits. Même si les principes sont fortement similaires à ceux employés dans IPv4, cet adressage apparaît à première vue beaucoup plus complexe. Il est intéressant d'en comprendre le principe et les règles d'attribution avant d'aborder les aspects protocolaires.

Ce chapitre présente les différents types d'adresses. Il explique en détail le plan d'adressage agrégé qui a été retenu pour construire l'Internet IPv6. Il décrit également la manière de constituer une adresse IPv6.

= Aspects fondamentaux de l'adressage IPv6=

==<div id="representation">Représentation des adresses ==

La représentation textuelle d'une adresse IPv6 se fait en découpant le mot de 128 bits de l'adresse en 8 mots de 16 bits séparés par le caractère «:», chacun d'eux étant représenté en hexadécimal. Par exemple :

<tt>2001:0DB8:0000:0000:0400:A987:6543:210F</tt>

Dans un champ, il n'est pas nécessaire d'écrire les zéros placés en tête :

<tt>2001:DB8:0:0:400:A987:6543:210F</tt>

En outre plusieurs champs nuls consécutifs peuvent être abrégés par «::». Ainsi l'adresse précédente peut s'écrire comme suit :

<tt>2001:DB8::400:A987:6543:210F</tt>

Naturellement, pour éviter toute ambiguïté, l'abréviation «::» ne peut apparaître qu'une fois au plus dans une adresse. Les cas extrêmes sont l'adresse indéfinie (utilisée pour désigner les routes par défaut) à tous les bits à zéro et qui se note de manière compacte :

<tt>::</tt>

et l'adresse de bouclage (loopback), équivalent du préfixe <tt>127/8</tt> dont tous les bits sont à zéro sauf le dernier et qui s'écrit :

<tt>::1</tt>

La représentation des préfixes réseau IPv6 est similaire à la notation CIDR RFC 1519 utilisée pour les préfixes IPv4. Un préfixe IPv6 est donc représenté par la notation :

adresse-ipv6/longueur-du-préfixe-en-bits

Les formes abrégées avec «::» sont autorisées.

<tt>2001:0DB8:7654:3210:0000:0000:0000:0000/64
2001:DB8:7654:3210:0:0:0:0/64
2001:DB8:7654:3210::/64</tt>

Le seul piège de cette notation vient des longueurs de préfixes qui ne sont pas en frontière de «:». Ainsi le préfixe <tt>3EDC:BA98:7654:3::/56</tt> équivaut en réalité à <tt>3EDC:BA98:7654:0000::/56</tt> car il s'écrit <tt>3EDC:BA98:7654:0003::/56</tt>.

On peut combiner le préfixe réseau avec l'identifiant de l'interface en une seule notation. Ainsi cette adresse IPV6
<tt>2001:DB8:7654:3210:945:1321:ABA8:F4E2/64</tt>
indique que le préfixe réseau est constitué par les 64 premiers bits.

Ces représentations peuvent apparaître beaucoup plus complexes qu'avec IPv4, mais en vérité des adresses logiques ou concises peuvent être constituées au moyen de règles strictes. Ces règles favorisent grandement la manipulation et la mémorisation des adresses comme nous verrons par la suite (cf Adressage global)

{{HorsTexte|Du fait de sa longueur, une règle de bonne gestion consiste à relâcher les contraintes sur les longueurs de préfixe. Ainsi en utilisant quand cela est possible des multiples de 4 permet d'avoir un préfixe qui tient sur un caractère affiché. Dans l'exemple suivant 47 n'étant pas un multiple de 4, <tt>2001:DB0:1234::/47</tt> représente les préfixes commençant par <tt>2001:DB0:1234</tt> et <tt>2001:DB0:1235</tt>}}

Dans certains cas, une adresse (voire plusieurs adresses) IPv4 peut être contenue dans une adresse IPv6. Pour les faire ressortir, la notation classique d'IPv4, c'est à dire 4 octets en représentation décimale séparés par des points, peut être utilisée au sein d'une adresse IPv6. Ainsi :

<tt>::128.12.13.14</tt>

représente une adresse IPv6 composée de 96 bits à 0 suivis des 32 bits de l'adresse IPv4 <tt>128.12.13.14</tt>

Il est pourtant parfois nécessaire de manipuler littéralement des adresses IPv6. Le caractère ":" utilisé pour séparer les mots peut créer des ambiguïtés. C'est le cas avec les URL où il est aussi utilisé pour indiquer le numéro de port. Ainsi l'URL

<tt><nowiki>http://2001:DB8:12::1:8000/</nowiki></tt>

peut aussi bien indiquer le port 8000 sur la machine ayant l'adresse IPv6 2001:DB8:12::1, que la machine 2001:DB8:12::1:8000 en utilisant le port par défaut. Pour lever cette ambiguïté, le RFC 2732 propose d'inclure l'adresse IPv6 entre "[ ]". L'adresse précédente s'écrirait :

<tt><nowiki>http://[2001:DB8:12::1]:8000/</nowiki></tt>

ou

<tt><nowiki>http://[2001:DB8:12::1:8000]/</nowiki></tt>

suivant les cas. Cette représentation peut être étendue à d'autres domaines comme X-window ou au protocole de signalisation téléphonique SIP.

== Type des adresses ==

IPv6 reconnaît trois types d'adresses : unicast, multicast et anycast. Le type d'adresse définit la cardinalité de la communication: à combien de destinataire doit être remis le paquet.

Le premier de ces types désigne de manière unique une interface. Un paquet envoyé à une telle adresse, sera donc remis à l'interface ainsi identifiée. Parmi les adresses unicast, on peut distinguer celles qui auront une portée globale, c'est-à-dire désignant sans ambiguïté une destination sur le réseau Internet et celles qui auront une portée locale (lien ou site). Ces dernières ne pourront pas être routées sur l'Internet c'est à dire qu'un paquet comportant une adresse de destination avec une portée locale sera ignoré et éliminé par un routeur de l'Internet. La portée d'une adresse indique en faite la limite de la propriété d'unicité.

Une adresse de type multicast désigne un groupe d'interfaces qui en général appartiennent à des noeuds différents pouvant être situés n'importe où dans l'Internet. Lorsqu'un paquet a pour destination une adresse de type multicast, il est acheminé par le réseau à toutes les interfaces membres de ce groupe.

Il faut noter qu'il n'y a plus d'adresses de type broadcast comme sous IPv4 ; elles sont remplacées par des adresses de type multicast. En effet, l'adresse de broadcast peut être émulée avec une adresse multicast en constituant un groupe qui comporte tous les noeuds. De plus, l'absence de broadcast évite les problèmes de saturation des réseaux locaux commutés. Ainsi un réseau IPV6 passe mieux en terme de facteur d'échelle sur ce type de réseau.

Le dernier type, anycast, est une officialisation de propositions faites pour IPv4 RFC 1546. Comme dans le cas du multicast, une adresse de type anycast désigne un groupe d'interfaces, la différence étant que lorsqu'un paquet a pour destination une telle adresse, il est acheminé à un des éléments du groupe et non pas à tous. C'est, par exemple, le plus proche au sens de la métrique des protocoles de routage. Cet adressage est principalement expérimental, voir [[Anycast|Adresses anycast]].

Certains types d'adresses sont caractérisés par leur préfixe RFC 3513. Le tableau suivant (source : http://www.iana.org/assignments/ipv6-address-space) donne la liste de ces préfixes. La plage «réservée» du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70% de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.

{|
!Préfixe IPv6!!Allouer!!Référence
|-style="background:silver"
|<tt>0000::/8</tt>||[[Autres types d'adresses|Réservé pour la transition et loopback]]||RFC 3513
|-
|<tt>0100::/8</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>0200::/7</tt>||Réservé (ex [[Autres types d'adresses#Les adresses NSAP|NSAP]])||RFC 4048
|-
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 3513
|-style="background:silver"
|<tt>0800::/5</tt>||Réservé||RFC 3513
|-
|<tt>1000::/4</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>2000::/3</tt>||[[Unicast Global]]||RFC 3513
|-
|<tt>4000::/3</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>6000::/3</tt>||Réservé||RFC 3513
|-
|<tt>8000::/3</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>A000::/3</tt>||Réservé||RFC 3513
|-
|<tt>C000::/3</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>E000::/4</tt>||Réservé||RFC 3513
|-
|<tt>F000::/5</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>F800::/6</tt>||Réservé||RFC 3513
|-
|<tt>FC00::/7</tt>||[[Site-local#ula|Unique Local Unicast]]||RFC 4193
|-style="background:silver"
|<tt>FE00::/9</tt> ||Réservé||RFC 3513
|-
|<tt>FE80::/10</tt>||[[Lien-local]]||RFC 3513
|-style="background:silver"
|<tt>FEC0::/10</tt>||Réservé||RFC 3879
|-
|<tt>FF00::/8</tt>||Multicast||RFC 3513
|}

Une interface possèdera généralement plusieurs adresses IPv6. En IPv4 ce comportement est exceptionnel, il est banalisé en IPv6.

= Adressage global : plan d'adressage agrégé =

Ce plan, proposée dans le RFC 3587, précise la structure d'adressage IPv6 définie dans le RFC 3513 en précisant les tailles de chacun des blocs. Il est géré de la même manière que CIDR en IPv4. Une adresse intègre trois niveaux de hiérarchie :

<tikz title="Adresses Globales">
\clip (0.0, 0) rectangle (11.5,7);
% \draw[help lines] (0,0) grid (10,6);

% \draw (0, 6.6) node [right] {Global Unicast Address:};

\draw (0,5) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tt{001}};
\draw (1,5) node [right, draw, shade, top color = green, minimum width=3cm, minimum height=1cm] {Global Prefix};
\draw (4,5) node [right, draw, shade, top color = blue, minimum width=1.5cm, minimum height=1cm] {SID};
\draw (5.5,5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.5, 5.7) node {\tiny{3}};
\draw (2.5, 5.7) node {\tiny{45}};
\draw (4.7, 5.7) node {\tiny{16}};
\draw (8, 5.7) node {\tiny{64}};

\draw [snake=brace, mirror snake] (0, 4.20) -- (4, 4.20) node [below, midway] {\tiny{
\ifthenelse{\equal{francais}{true}}{Topologie Publique}{public topology}}
} node [below = 8pt, midway] {\tiny{given by the provider}} ;
\draw [snake=brace, mirror snake] (4, 4.20) -- (5.5, 4.20) node [below, midway] {\tiny{local topology}} node [below = 8pt, midway] {\tiny{assigned by network engineer}} ;
\draw [snake=brace, mirror snake] (5.5, 4.20) -- (10.3, 4.20) node [below, midway] {\tiny{link address}} node [below = 8pt, midway] {\tiny{auto or manual configuration}} ;
</tikz>

* une topologie publique (appelée '''Global Prefix''') codée sur 48 bits, allouée par le fournisseur d'accès;
* une topologie de site codée sur 16 bits (appelée '''Subnet ID'''). Ce champ permet de coder les numéros de sous réseau du site;
* un [[identifiant d'interface]] sur 64 bits (appelé '''Interface ID''') distinguant les différentes machines sur le lien.

==Structuration du prefixe global (GP)==

{{HorsTexte|Appréhender les tailles|France Télécom a obtenu du RIPE-NCC un <tt>/19</tt>. Si l'on enlève les troix premiers bits <tt>001</tt> désignant le plan d'adressage, il est donc possible d'avoir 216 opérateurs. Sachant qu'il y a 192 pays à l'ONU, ils pourraient chacun abriter 320 opérateurs de la taille de FT, chacun pouvant attribuer jusqu'à 229 <tt>/48</tt>, soit 536 870 912 sites}}

A part le préfixe <tt>2002::</tt> qui est est réservé au mécanisme de transition [[6to4]], cet espace est géré hierarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales ([http://www.iana.org/numbers/ RIR]) des préfixes actuellement de longueur 12 (cf. http://www.iana.org/assignments/ipv6-unicast-address-assignments) qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long. Le site http://www.sixxs.net/tools/grh/ donne en temps réel les allocations de préfixes par région, opérateur et pays.

Il est maintenant admis que le préfixe attribué par un opérateur à ses clients peut également être un <tt>/56</tt>. En effet, si l'on garde l'attribution de préfixe de longueur 48 pour les sites terminaux, et que l'on intègre les réseaux domotiques, les opérateurs peuvent justifier d'un besoin important d'adresses que les autorités régionales ne peuvent leur refuser.

{{ToDo|Ajouter comment obtenir un préfixe auprès de RIPE-NCC}}

==Structuration de l'identifiant de sous-réseau (SID)==

Il n'existe pas de règles pour allouer les identificateurs de sous-réseau au sein d'un site. Plusieurs techniques (non exclusives) peuvent être utilisées :

* numéroter de manière incrémentale les sous-réseaux: 0001, 0002, ... Cette technique est simple a mettre en œuvre dans des réseaux expérimentaux, mais elle peut conduire à un plan d'adressage à plat difficile à mémoriser. Elle peut être utilisée par exemple pour un sous-réseau dédié aux serveurs pour simplifier l'écriture et la mémorisation des adresses.
* utiliser le numéro de VLAN. Elle permet d'éviter de mémoriser plusieurs niveaux de numérotation.
* séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau suivant contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs :

{|
!Communauté !! 4bits !! width="50%"|8bits !! 4bits
|-style="background:silver"
| Infrastructure || 0 || colspan=2 | valeurs spécifiques
|-
| Tests || 1 || colspan=2 | valeurs spécifiques
|-style="background:silver"
| Tunnels || 6 || colspan=2 | allocation de /60 aux utilisateurs
|-
| Invités Wi-Fi || 8 || colspan=2 | valeurs spécifiques
|-style="background:silver"
| Personnels || A || Entité || Sous-Réseaux
|-
| Etudiants || E || Entité || Sous-Réseaux
|-style="background:silver"
| Autres (Start up, etc.) || F || colspan=2 | valeurs spécifiques
|+ Affectation des SID dans une université
|}

Ainsi, le préfixe:
* <tt>2001:DB8:1234::/52</tt> servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs seront prises dans cet espace;
* <tt>2001:DB8:1234:8000::/52</tt> servira pour le réseau Wi-Fi des invités. La manière dont sont gérés les 12 bits restants du SID ne sont pas spécifiés;
* <tt>2001:DB8:1234:E000::/52</tt> servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.

=== Adressage local : adresses lien-local ===

Les adresses de type lien-local (''link local use address'') sont des adresses dont la validité est restreinte à un lien, c'est-à-dire l'ensemble de interfaces directement connectées sans routeur intermédiaire comme par exemple des machines branchées sur un même réseau Ethernet, des machines reliées par une connexion PPP, ou des extrémités d'un tunnel. Les adresses lien-local sont configurées automatiquement à l'initialisation de l'interface et permettent la communication entre nœuds voisins. L'adresse est obtenue en concaténant le préfixe <tt>FE80::/64</tt> aux 64 bits de l'[[Identifiant d'interface|identifiant d'interface]]. L'identifiant d'interface est généralement basé sur l'adresse MAC. Cela ne pose pas de problème de respect de le vie privée car, contrairement aux adresses globales, les adresses lien-local ne sortent jamais du réseau où elles sont utilisées.

<tikz title="Adresses Lien-local">
% \draw (0, 3) node [right] {Link-Local Address:};
\draw (0,1.5) node [right, draw, shade, top color = yellow, minimum width=1.5cm, minimum height=1cm] {FE80};
\draw (1.5,1.5) node [right, draw, minimum width=4cm, minimum height=1cm] {0...0};
\draw (5.5,1.5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.7, 2.2) node {\tiny{10}};
\draw (3.5, 2.2) node {\tiny{54}};
\draw (8, 2.2) node {\tiny{64}};

\draw [snake=brace, mirror snake] (5.5, 0.8) -- (10.3, 0.8) node [below, midway] {\tiny{link address}} node [below = 8pt, midway] {\tiny{auto-configuration}} ;
</tikz>

Ces adresses sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins (''neighbor discovery'') et de découverte de routeurs (''router discovery''). Ce sont de nouveaux dispositifs, le premier supplantant en particulier le protocole ARP (''Address Resolution Protocol''), qui permettent à un réseau local de se configurer automatiquement (voir [[Découverte de voisins]]). Elles sont également largement utilisées par les protocoles de routage soit pour l'échange de données (cf. RIPng, OSPFv3), soit dans les tables de routage puisque le champ ''prochain routeur'' est toujours un équipement directement accessible sur le lien.
{{HorsTexte|Unicité sur le lien|Les adresses lien-local sont uniques à l'intérieur d'un lien. Le protocole de détection de duplication d'adresses (voir [[Configuration automatique#DAD|Détection d'adresse dupliquée]]) permet de s'en assurer. Par contre la duplication d'une adresse lien-local entre deux liens différents, ou entre deux interfaces d'un même nœud est autorisée.}}

Un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type lien-local.

Le fait que ces adresses aient une portée très faible les limite dans la pratique au cas où un démarrage automatique (''bootstrap'') est nécessaire. Leur usage ne doit pas être généralisé dans les applications classiques en régime stabilisé.

==== Portée de l'adresse (''scoped address'') ====

Une adresse lien-local (ou multicast) n'indique pas intrinsèquement l'interface de sortie, puisque toutes les interfaces partagent le même préfixe <tt>fe80::/10</tt>. Il faut donc indiquer de manière explicite sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère "%". Sous Linux, un argument, généralement <tt>-I</tt> permet de la désigner.

===Unique Local Address===

Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local Address''). Ces adresses sont destinées à une utilisation locale. Elles ne sont pas définies pour être routées dans l'Internet, mais seulement au sein d'une zone limitée telle qu'un site ou entre un nombre limité de sites. Les adresses uniques locales ont les caractéristiques suivantes :

* Prefixe ''globalement'' unique;
* Préfixe clairement défini facilitant le filtrage sur les routeurs de bordure;
* Permet l'interconnexion de sites sans générer de conflit d'adresse et sans nécessiter de renumérotation;
* Indépendantes des fournisseurs d'accès à l'Internet et ne nécessitent donc pas de connectivité;
* Pas de conflit en cas de routage par erreur en dehors d'un site;
* Aucune différence pour les applications, qui peuvent les considérer comme des adresses globales unicast standard.

<tikz title="Unique Local Addresses">
\clip (0, 0) rectangle (11,4);
% \draw[help lines] (0,0) grid (10,3);

% \draw (0, 3.6) node [right] {Unique Local IPv6 Unicast Addresses:};

\draw (0,2) node [right, draw, shade, top color = yellow, minimum width=1.5cm, minimum height=1cm] {FD};
\draw (1.5,2) node [right, draw, shade, top color = green, minimum width=3cm, minimum height=1cm] {Random Value};
\draw (4.5,2) node [right, draw, shade, top color = blue, minimum width=1cm, minimum height=1cm] {SID};
\draw (5.5,2) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.7, 2.7) node {\tiny{8}};
\draw (2.7, 2.7) node {\tiny{40}};
\draw (4.7, 2.7) node {\tiny{16}};
\draw (8, 2.7) node {\tiny{64}};

\draw [snake=brace, mirror snake] (0, 1.20) -- (4.5, 1.20) node [below, midway] {\tiny{private topology}} node [below = 8pt, midway] {\tiny{Not Routable in the Internet}} ;
\draw [snake=brace, mirror snake] (4.5, 1.20) -- (5.5, 1.20) node [below, midway] {\tiny{local topology}};
\draw [snake=brace, mirror snake] (5.5, 1.20) -- (10.3, 1.20) node [below, midway] {\tiny{link address}} ;
</tikz>

Les adresses uniques locales sont créées en utilisant un identifiant global (''Global ID'') généré pseudo-aléatoirement. Ces adresses suivent le format suivant :

* <tt>Prefix</tt> (7 bits) : <tt>FC00::/7</tt> préfixe identifiant les adresses IPv6 locales (''ULA'')
* <tt>L</tt> (1 bit) : Positionné à 1, le préfixe est assigné localement. La valeur 0 est réservée pour une utilisation future.
* <tt>Global ID</tt> (40 bits) : Identifiant global utilisé pour la création d'un préfixe ''unique'' (''Globally Unique Prefix'').
* <tt>Subnet ID</tt> (16 bits) : Identifiant d'un sous réseau à l'intérieur du site.
* <tt>Interface ID</tt> (64 bits) : L'indentifiant d'interface tel que défini dans [[Identifiant d'interface]].

Le site http://www.sixxs.net/tools/grh/ula/ permet de créer et d'enregistrer son adresse ULA à partir d'une adresse MAC.

= Structuration de l'identifiant d'interface (IID) =

Si initialement pour des raisons d'auto-configuration, l'identifiant d'interface devait toujours être dérivé de l'adresse de niveau 2, c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits:

* manuelle,
* basée sur l'adresse de niveau 2 de l'interface,
* aléatoire,
* cryptographique.

== Manuel ==
{{HorsTexte|Le resolveur DNS|Le résolveur DNS est le cas le plus flagrant; chaque machine sur le réseau doit être configurée avec l'adresse IPv6 du serveur DNS. En cas de changement de carte réseau, l'ensemble des machines du domaine devront être reconfigurées. Si l'on ne souhaite pas utiliser des protocoles de configuration automatique de type DHCPv6, il est préférable d'attribuer au résolveur DNS une adresse manuelle.}}
Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces, car dans ce cas l'adresse IPv6 est facilement mémorisable, et le serveur peut être accessible même si le DNS n'est pas actif.
Il existe plusieurs techniques plus ou moins mnémotechniques :
* incrémenter l'identifiant d'interface à chaque nouveau serveur créé

<tt>2001:DB8:1234:1::1</tt>
<tt>2001:DB8:1234:1::2</tt>
...

* reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple si un serveur a comme adresse IPv4 <tt>192.0.2.123</tt>, son adresse IPv6 sera :

<tt>2001:DB8:1234:1::7B</tt>
ou plus simplement
<tt>2001:DB8:1234:1::123</tt>

* reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à taper :

<tt>2001:DB8:1234:1::192.0.2.123</tt>

== Dérivé de l'adresse de l'interface==

L'avantage d'utiliser une adresse de niveau 2 pour construire un identifiant d'interface est que l'unicité de cette valeur est presque toujours assurée. En plus, cette valeur est stable tant que la carte réseau de la machine n'est pas changée. Par contre, ces valeurs sont difficilement mémorisables.

Les adresses lien-local sont construites en utilisant ce type d'identifiant. Par contre pour les adresses globales, il est conseillé de ne les utiliser que pour les machines client et de préférer les identifiants d'interface manuels pour les serveurs.

Ces identifiants d'interface étant stables dans le temps, à chaque fois qu'un individu change de réseau, il change de préfixe, mais garde le même identifiant d'interface. Ce dernier pourrait donc servir à tracer les déplacements d'un individu. Le risque est faible, car les cookies mis en place par les serveurs web sont bien plus efficaces, mais ils ne s'agit plus d'un problème réseau. Autre désavantage, comme les adresses MAC contiennent l'identification du matériel, il est possible d'indiquer à l'exterieur du réseau quel type de materiel est utilisé et donner des indications.

Si ces inconvénients sont jugés importants par l'entreprise, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement.

=== EUI-64 ===

<tikz title="Transformation d'une adresse MAC en identifiant d'interface">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{u}g}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (5, 1.5) node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};

</tikz>

L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (firewire) ou IEEE 802.15.4 (réseau de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64.

Il existe plusieurs méthodes pour construire l'identifiant :
{{HorsTexte|Ordre de transmission|L'ordre des bits ne doit pas porter à confusion. Dans la représentation numérique des valeurs, le premier bit transmis est le bit de poids faible, c'est-à-dire le bit de droite. Ainsi sur le support physique le bit <tt>g</tt>, puis le bit <tt>u</tt> puis les bits suivants sont transmis. }}

* Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure décrite figure Identificateur global IEEE EUI-64.
: Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802, identifient le constructeur et les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits <tt>u</tt> (septième bit du premier octet) et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :
:* <tt>u</tt> (Universel) vaut <tt>0</tt> si l'identifiant EUI-64 est universel,
:* <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g = 0</tt>), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g = 1</tt>), par exemple une adresse de multicast.

<tikz title="Identificateur d'interface dérivé d'une EUI-64">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (5, 1.5) node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};

</tikz>
* L'identifiant d'interface à 64 bits est dérivé de l'EUI-64 en inversant le bit <tt>u</tt> (cf. figure Identificateur d'interface dérivé d'une EUI-64). En effet, pour la construction des adresses IPv6, on a préféré utiliser <tt>1</tt> pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur <tt>0</tt> pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de <tt>1</tt>.

===MAC-48===

<tikz title="Transformation d'une adresse MAC en identifiant d'interface">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\only<2-> {
\draw (3, 4.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
\draw (4, 4.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (3, 4.25) rectangle+(3, 0.5);

\draw (0,4.5) node [right] {MAC-48};

\draw (6, 4.5) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (2, 3) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
\draw (3, 3) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 2.75) rectangle+(3, 0.5);

\draw (7, 3) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (6,4.5) -- (6, 4) -- (5, 3.5) -- (5, 3);
\draw (6,4) -- (7, 3.5) -- (7, 3);
\draw (3, 4.5) -- (3, 4) -- (2, 3.5) -- (2, 3);
\draw (9, 4.5) -- (9, 4) -- (10, 3.5) -- (10, 3);

\draw (5, 3) node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};

\draw (0,3) node [right] {EUI-64};
}

\only<3-> {

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (7, 1.5) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (5, 1.5) node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};

\draw (2,3) -- (2, 1.5);
\draw (10,3) -- (10, 1.5);
\draw (0,1.5) node [right] {IID};
}

</tikz>

* Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi). L'adresse est tout d'abord convertie en EUI-64, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure ci-contre illustre ce processus.

===Cas Particuliers===
* Si une interface possède une adresse locale unique sur le lien, mais non universelle (par exemple le format d'adresse IEEE 802 sur 2 octets ou une adresse sur un réseau Appletalk), l'identifiant d'interface est construit à partir de cette adresse en rajoutant des 0 en tête pour atteindre 64 bits.

{{HorsTexte|Erreur de l'IETF|À noter que l'IETF s'est trompée quand elle a défini l'algorithme de conversion. En effet, l'ajout de la valeur <tt>0xFFFE</tt> concerne les EUI-48, c'est-à-dire des identifiants, alors qu'Ethernet utilise des MAC-48, c'est-à-dire des adresses (ils servent à transporter des trames vers le bon destinataire). La bonne valeur aurait été <tt>0xFFFF</tt>. Mais cette erreur n'a aucune conséquence pour l'identification des équipements, elle n'a donc pas été corrigée par la suite.}}

* Si une interface ne possède aucune adresse (par exemple l'interface utilisée pour les liaisons PPP), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle ou bien une génération aléatoire, avec le bit u positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, et devra être résolu manuellement.

== Valeur aléatoire ==

L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pourrait poser des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur, qui même s'il se déplace de réseau en réseau garde ce même identifiant. Il serait alors possible de traquer un individu utilisant un portable, chez lui, au bureau, lors de ses déplacements. Ce problème est similaire à l'identificateur placé dans les processeurs Pentium III.

[[image:Windows7-IIDalea.png|500px|right]]

Pour couper court à toute menace de boycott d'un protocole qui « menacerait la vie privée », il a été proposé d'autres algorithmes de construction d'un identifiant d'interface basé sur des tirages aléatoires (voir RFC 3041). Un utilisateur particulièrement méfiant pourrait valider ces mécanismes. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme comme MD5 à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.

Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globale. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (i.e. les applications serveur). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours et sert aux applications client. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur Linux et les système d'exploitation BSD comme Mac OS.

Bien entendu pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse ou que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit impossible.

En contre partie, il est plus difficile à un administrateur réseau de filtrer les machines puisque celles-ci changent périodiquement d'adresses.

== Cryptographique ==

{{HorsTexte|Encore un sujet de recherche|L'usage de ces adresses n'est pas encore généralisé. Shim6 pour la gestion de la multi-domiciliation ou SEND pour sécuriser la découverte de voisins y ont recours.}}
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.

=Adresses Multicast=
{{HorsTexte|Portée et portée|Il ne faut pas confondre la portée d'une adresse link-local ou multicast qui désigne l'interface par laquelle sera émis le paquet et la portée d'un groupe multicast qui désigné l'étendue de la couverture}}
Cette section décrit brièvement le système d'adressage multicast IPv6 et ne s'intéresse qu'aux adresses utilisées localement par les protocoles directement liés à IPv6 (Découverte de voisins, DHCPv6,...). Pour plus de détails sur le multicast en général, se reporter au chapitre [[Multicast]]. La figure Structure de l'adresse IPv6 Multicast donne le format de l'adresse IPv6 de multicast décrite dans le RFC 3513.

<tikz title="Structure de l'adresse IPv6 Multicast">
\clip (0, 1) rectangle (11,4);
% \draw[help lines] (0,0) grid (10,4 );

% \draw (0, 3.6) node [right] {Generic Format:};

\draw (0,2) node [right, draw, shade, top color = yellow, minimum width=2cm, minimum height=1cm] {FF};
\draw (2,2) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tiny{\tt{xRPT}}};
\draw (3,2) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tiny{scope}};
\draw (4,2) node [right, draw, shade, top color = black!50, minimum width=6cm, minimum height=1cm] {Group ID};

\draw (1, 2.7) node {\tiny{8}};
\draw (2.5, 2.7) node {\tiny{4}};
\draw (3.5, 2.7) node {\tiny{4}};
\draw (7, 2.7) node {\tiny{112}};

</tikz>

Les adresses multicast IPv6 sont dérivées du préfixe <tt>FF00::/8</tt>. Le champ drapeaux de 4 bits est défini de la manière suivante :

* Seul le bit <tt>T</tt> (comme ''Transient'') du champ drapeaux est initialement décrit dans le RFC 3513. La valeur <tt>0</tt> indique une adresse multicast bien connue gérée par une autorité. La valeur <tt>1</tt> indique une valeur temporaire.
* Les bits <tt>P</tt> et <tt>R</tt> sont décrits dans le RFC 3306 et le draft Internet sur embedded-RP (RFC 3956).
* Le bit de poids fort du champ drapeaux n'est pas encore attribué.

Le champ drapeaux permet de définir plusieurs types d'adresses multicast IPv6 qui seront décrits dans les sections suivantes.

Le champ scope de l'adresse multicast IPv6 permet d'en limiter la portée (''scope'' en anglais). En IPv4, la portée d'un paquet est limitée par le champ TTL (''Time To Live''), de même des préfixes peuvent être définis pour identifier des adresses à portée réduite. Les valeurs suivantes sont définies dans la RFC 2373 :

* 1 - node-local : Les paquets ne sortent pas de la machine, cette adresse sert pour la communication entre les applications.
* 2 - link-local : La portée se limite au réseau local, les paquets ne peuvent pas traverser les routeurs multicast. Cette valeur est utilisée en particulier par le protocole de découverte des voisins.
* 3 - subnet-local : Ce type n'est pas officiellement défini, mais se retrouve dans certains documents. Il permet de faire la différence entre un lien physique et un lien logique (regroupement de plusieurs liens physiques) partageant le même préfixe IPv6.
* 4 - admin-local
* 5 - site-local
* 8 - organisation-local
* E - global
* Les portées 0 et F sont réservées.

http://www.iana.org/assignments/ipv6-multicast-addresses donne les adresses multicast définies. Le tableau ci-dessous liste les plus utilisées :

{|
!Adresse multicast !! usage
|-style="background:silver"
| FF01::1 || All Nodes Address
|-
| FF01::2 || All Routers Address
|-style="background:silver"
| FF02::1 || All Nodes Address
|-
| FF02::2 || All Routers Address
|-style="background:silver"
| FF02::5 || OSPFIGP
|-
| FF02::6 || OSPFIGP Designated Routers
|-style="background:silver"
| FF02::9 || RIP Routers
|-
| FF02::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-style="background:silver"
| FF02::1:2 || All-dhcp-agents
|-
| FF03::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-style="background:silver"
| FF04::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-
| FF05::2 || All Routers Address
|-style="background:silver"
| FF05::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-
| FF05::1:3 || All-dhcp-servers
|-style="background:silver"
| FF0X::101 || Network Time Protocol (NTP)
|}

==Adressage Multicast Sollicité==

IPv6 interdit l'utilisation de la diffusion généralisée (Broadcast) lorsque le Multicast est disponible. Ainsi les protocoles comme Neighbor Discovery, chargé de faire le lien entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse de Multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>FF02::1</tt> (tous les équipements sur le lien, l'utilisation des adresses de multicast sollicité permet de réduire considérablement le nombre d'équipements qui recevront la requête.

<tikz title="Construction de l'adresse de Multicast sollicité">
\clip (0, 0) rectangle (10,4);
%\draw[help lines] (0,0) grid (10,4 );

\draw (2, 3.75) node (mac) [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{01-02-03-04-05-06}}};

\draw (0, 2.75) node (LL) [right, draw, shade, top color = green!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{FE80::0102:03FF:FE04:0506}}};

\draw (4, 2.75) node (GP) [right, draw, shade, top color = green!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{GP:0102:03FF:FE04:0506}}};

\draw [->] (mac) -- (LL);
\draw [->] (mac) -- (GP);

\draw (8, 2.75) node (manuel) [right, draw, shade, top color = green!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{GP::1}}};

\draw (2.5, 1.75) node (MS1) [right, draw, shade, top color = red!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{FF02::1:FF04:0506}}};
\draw [->] (LL) -- (MS1);
\draw [->] (GP) -- (MS1);

\draw (7.4, 1.75) node (MS2) [right, draw, shade, top color = red!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{FF02::1:FF00:0001}}};
\draw [->] (manuel) -- (MS2);

\draw (2.5, 0.75) node (mac2) [right, draw, shade, top color = blue!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{33-33-FF-04-05-06}}};
\draw [->] (MS1) -- (mac2);

\draw (7.4, 0.75) node (mac3) [right, draw, shade, top color = blue!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{33-33-FF-00-00-01}}};
\draw [->] (MS2) -- (mac3);
</tikz>

La figure Construction de l'adresse de Multicast sollicité montre comment l'on passe d'une adresse IPv6 unicast à une adresse de multicast sollicité. Il s'agit de prendre les 3 derniers octets de l'adresse unicast que l'on concatène avec le préfixe IPv6 multicast <tt>FF02::1:FF00:0/104</tt>.

Dans l'exemple, les deux adresses dérivant d'une adresse MAC conduisent à la même adresse de multicast sollicité, tandis que la configuration manuelle d'une interface conduit à la construction d'une autre adresse de multicast sollicité. On peut noter que le risque que deux machines sur un lien aient la même adresse de multicast sollicité est très faible. Pour celles dérivant d'une adresse MAC, il faudrait que les 3 derniers octets soient identiques, ce qui est impossible chez un même constructeur et la probabilité d'avoir, sur un même lien, des cartes de deux constructeurs différents se terminant par les mêmes 3 derniers octets est très faible. Pour la numérotation manuelle des interfaces, une machine ayant l'adresse <tt>GP:::0100:0001</tt> conduirait à construire la même adresse de multicast sollicité <tt>FF02::1:FF00:0001</tt>, mais cette numérotation manuelle des interfaces n'est pas logique.

{{HorsTexte|Sollicitation des voisins|L'algorithme de découverte des adresses de niveau 3 des voisins (inclus dans Neighbor Discovery) fonctionne de la manière suivante. La machine qui recherche un voisin dont elle connait l'adresse IPv6, effectue l'algorithme décrit précédemment. Elle émet la requête en utilisant l'adresse MAC obtenue. Seule la machine qui possède cette adresse est abonnée à ce groupe, elle sera donc la seule à traiter la requête et à y répondre.}}

L'exemple se poursuit par la transformation de l'adresse de Multicast au niveau IPv6 en adresse de multicast de niveau 2. Elle est très spécifique à la technologie et à la manière dont est mis en œuvre le multicast au niveau 2. Pour les réseaux Ethernet (et dérivés comme le Wi-Fi), les 4 derniers octets de l'adresse multicast sollicité sont ajoutés au préfixe <tt>33-33</tt>.
{{Suivi| Introduction|Introduction | AdressageBis-MeO|Mises en Oeuvre}}

AdressageBis-Fondamentaux

2011-12-25T15:38:52Z

Ltoutain:

{{Suivi| Introduction|Introduction | AdressageBis-MeO|Mises en Oeuvre}}

Le format et la représentation des adresses sont les modifications les plus visibles pour l'utilisateur expérimenté et l'ingénieur réseau dans cette nouvelle version du protocole. En effet la taille de l'adresse reste fixe mais passe de 32 à 128 bits. Même si les principes sont fortement similaires à ceux employés dans IPv4, cet adressage apparaît à première vue beaucoup plus complexe. Il est intéressant d'en comprendre le principe et les règles d'attribution avant d'aborder les aspects protocolaires.

Ce chapitre présente les différents types d'adresses. Il explique en détail le plan d'adressage agrégé qui a été retenu pour construire l'Internet IPv6. Il décrit également la manière de constituer une adresse IPv6.

= Aspects fondamentaux de l'adressage IPv6=

==<div id="representation">Représentation des adresses ==

La représentation textuelle d'une adresse IPv6 se fait en découpant le mot de 128 bits de l'adresse en 8 mots de 16 bits séparés par le caractère «:», chacun d'eux étant représenté en hexadécimal. Par exemple :

<tt>2001:0DB8:0000:0000:0400:A987:6543:210F</tt>

Dans un champ, il n'est pas nécessaire d'écrire les zéros placés en tête :

<tt>2001:DB8:0:0:400:A987:6543:210F</tt>

En outre plusieurs champs nuls consécutifs peuvent être abrégés par «::». Ainsi l'adresse précédente peut s'écrire comme suit :

<tt>2001:DB8::400:A987:6543:210F</tt>

Naturellement, pour éviter toute ambiguïté, l'abréviation «::» ne peut apparaître qu'une fois au plus dans une adresse. Les cas extrêmes sont l'adresse indéfinie (utilisée pour désigner les routes par défaut) à tous les bits à zéro et qui se note de manière compacte :

<tt>::</tt>

et l'adresse de bouclage (loopback), équivalent du préfixe <tt>127/8</tt> dont tous les bits sont à zéro sauf le dernier et qui s'écrit :

<tt>::1</tt>

La représentation des préfixes réseau IPv6 est similaire à la notation CIDR RFC 1519 utilisée pour les préfixes IPv4. Un préfixe IPv6 est donc représenté par la notation :

adresse-ipv6/longueur-du-préfixe-en-bits

Les formes abrégées avec «::» sont autorisées.

<tt>2001:0DB8:7654:3210:0000:0000:0000:0000/64
2001:DB8:7654:3210:0:0:0:0/64
2001:DB8:7654:3210::/64</tt>

Le seul piège de cette notation vient des longueurs de préfixes qui ne sont pas en frontière de «:». Ainsi le préfixe <tt>3EDC:BA98:7654:3::/56</tt> équivaut en réalité à <tt>3EDC:BA98:7654:0000::/56</tt> car il s'écrit <tt>3EDC:BA98:7654:0003::/56</tt>.

On peut combiner le préfixe réseau avec l'identifiant de l'interface en une seule notation. Ainsi cette adresse IPV6
<tt>2001:DB8:7654:3210:945:1321:ABA8:F4E2/64</tt>
indique que le préfixe réseau est constitué par les 64 premiers bits.

Ces représentations peuvent apparaître beaucoup plus complexes qu'avec IPv4, mais en vérité des adresses logiques ou concises peuvent être constituées au moyen de règles strictes. Ces règles favorisent grandement la manipulation et la mémorisation des adresses comme nous verrons par la suite (cf Adressage global)

{HorsTexte|Du fait de sa longueur, une règle de bonne gestion consiste à relâcher les contraintes sur les longueurs de préfixe. Ainsi en utilisant quand cela est possible des multiples de 4 permet d'avoir un préfixe qui tient sur un caractère affiché. Dans l'exemple suivant 47 n'étant pas un multiple de 4, <tt>2001:DB0:1234::/47</tt> représente les préfixes commençant par <tt>2001:DB0:1234</tt> et <tt>2001:DB0:1235</tt>}

Dans certains cas, une adresse (voire plusieurs adresses) IPv4 peut être contenue dans une adresse IPv6. Pour les faire ressortir, la notation classique d'IPv4, c'est à dire 4 octets en représentation décimale séparés par des points, peut être utilisée au sein d'une adresse IPv6. Ainsi :

<tt>::128.12.13.14</tt>

représente une adresse IPv6 composée de 96 bits à 0 suivis des 32 bits de l'adresse IPv4 <tt>128.12.13.14</tt>

Il est pourtant parfois nécessaire de manipuler littéralement des adresses IPv6. Le caractère ":" utilisé pour séparer les mots peut créer des ambiguïtés. C'est le cas avec les URL où il est aussi utilisé pour indiquer le numéro de port. Ainsi l'URL

<tt><nowiki>http://2001:DB8:12::1:8000/</nowiki></tt>

peut aussi bien indiquer le port 8000 sur la machine ayant l'adresse IPv6 2001:DB8:12::1, que la machine 2001:DB8:12::1:8000 en utilisant le port par défaut. Pour lever cette ambiguïté, le RFC 2732 propose d'inclure l'adresse IPv6 entre "[ ]". L'adresse précédente s'écrirait :

<tt><nowiki>http://[2001:DB8:12::1]:8000/</nowiki></tt>

ou

<tt><nowiki>http://[2001:DB8:12::1:8000]/</nowiki></tt>

suivant les cas. Cette représentation peut être étendue à d'autres domaines comme X-window ou au protocole de signalisation téléphonique SIP.

== Type des adresses ==

IPv6 reconnaît trois types d'adresses : unicast, multicast et anycast. Le type d'adresse définit la cardinalité de la communication: à combien de destinataire doit être remis le paquet.

Le premier de ces types désigne de manière unique une interface. Un paquet envoyé à une telle adresse, sera donc remis à l'interface ainsi identifiée. Parmi les adresses unicast, on peut distinguer celles qui auront une portée globale, c'est-à-dire désignant sans ambiguïté une destination sur le réseau Internet et celles qui auront une portée locale (lien ou site). Ces dernières ne pourront pas être routées sur l'Internet c'est à dire qu'un paquet comportant une adresse de destination avec une portée locale sera ignoré et éliminé par un routeur de l'Internet. La portée d'une adresse indique en faite la limite de la propriété d'unicité.

Une adresse de type multicast désigne un groupe d'interfaces qui en général appartiennent à des noeuds différents pouvant être situés n'importe où dans l'Internet. Lorsqu'un paquet a pour destination une adresse de type multicast, il est acheminé par le réseau à toutes les interfaces membres de ce groupe.

Il faut noter qu'il n'y a plus d'adresses de type broadcast comme sous IPv4 ; elles sont remplacées par des adresses de type multicast. En effet, l'adresse de broadcast peut être émulée avec une adresse multicast en constituant un groupe qui comporte tous les noeuds. De plus, l'absence de broadcast évite les problèmes de saturation des réseaux locaux commutés. Ainsi un réseau IPV6 passe mieux en terme de facteur d'échelle sur ce type de réseau.

Le dernier type, anycast, est une officialisation de propositions faites pour IPv4 RFC 1546. Comme dans le cas du multicast, une adresse de type anycast désigne un groupe d'interfaces, la différence étant que lorsqu'un paquet a pour destination une telle adresse, il est acheminé à un des éléments du groupe et non pas à tous. C'est, par exemple, le plus proche au sens de la métrique des protocoles de routage. Cet adressage est principalement expérimental, voir [[Anycast|Adresses anycast]].

Certains types d'adresses sont caractérisés par leur préfixe RFC 3513. Le tableau suivant (source : http://www.iana.org/assignments/ipv6-address-space) donne la liste de ces préfixes. La plage «réservée» du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70% de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.

{|
!Préfixe IPv6!!Allouer!!Référence
|-style="background:silver"
|<tt>0000::/8</tt>||[[Autres types d'adresses|Réservé pour la transition et loopback]]||RFC 3513
|-
|<tt>0100::/8</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>0200::/7</tt>||Réservé (ex [[Autres types d'adresses#Les adresses NSAP|NSAP]])||RFC 4048
|-
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 3513
|-style="background:silver"
|<tt>0800::/5</tt>||Réservé||RFC 3513
|-
|<tt>1000::/4</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>2000::/3</tt>||[[Unicast Global]]||RFC 3513
|-
|<tt>4000::/3</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>6000::/3</tt>||Réservé||RFC 3513
|-
|<tt>8000::/3</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>A000::/3</tt>||Réservé||RFC 3513
|-
|<tt>C000::/3</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>E000::/4</tt>||Réservé||RFC 3513
|-
|<tt>F000::/5</tt>||Réservé||RFC 3513
|-style="background:silver"
|<tt>F800::/6</tt>||Réservé||RFC 3513
|-
|<tt>FC00::/7</tt>||[[Site-local#ula|Unique Local Unicast]]||RFC 4193
|-style="background:silver"
|<tt>FE00::/9</tt> ||Réservé||RFC 3513
|-
|<tt>FE80::/10</tt>||[[Lien-local]]||RFC 3513
|-style="background:silver"
|<tt>FEC0::/10</tt>||Réservé||RFC 3879
|-
|<tt>FF00::/8</tt>||Multicast||RFC 3513
|}

Une interface possèdera généralement plusieurs adresses IPv6. En IPv4 ce comportement est exceptionnel, il est banalisé en IPv6.

= Adressage global : plan d'adressage agrégé =

Ce plan, proposée dans le RFC 3587, précise la structure d'adressage IPv6 définie dans le RFC 3513 en précisant les tailles de chacun des blocs. Il est géré de la même manière que CIDR en IPv4. Une adresse intègre trois niveaux de hiérarchie :

<tikz title="Adresses Globales">
\clip (0.0, 0) rectangle (11.5,7);
% \draw[help lines] (0,0) grid (10,6);

% \draw (0, 6.6) node [right] {Global Unicast Address:};

\draw (0,5) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tt{001}};
\draw (1,5) node [right, draw, shade, top color = green, minimum width=3cm, minimum height=1cm] {Global Prefix};
\draw (4,5) node [right, draw, shade, top color = blue, minimum width=1.5cm, minimum height=1cm] {SID};
\draw (5.5,5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.5, 5.7) node {\tiny{3}};
\draw (2.5, 5.7) node {\tiny{45}};
\draw (4.7, 5.7) node {\tiny{16}};
\draw (8, 5.7) node {\tiny{64}};

\draw [snake=brace, mirror snake] (0, 4.20) -- (4, 4.20) node [below, midway] {\tiny{
\ifthenelse{\equal{francais}{true}}{Topologie Publique}{public topology}}
} node [below = 8pt, midway] {\tiny{given by the provider}} ;
\draw [snake=brace, mirror snake] (4, 4.20) -- (5.5, 4.20) node [below, midway] {\tiny{local topology}} node [below = 8pt, midway] {\tiny{assigned by network engineer}} ;
\draw [snake=brace, mirror snake] (5.5, 4.20) -- (10.3, 4.20) node [below, midway] {\tiny{link address}} node [below = 8pt, midway] {\tiny{auto or manual configuration}} ;
</tikz>

* une topologie publique (appelée '''Global Prefix''') codée sur 48 bits, allouée par le fournisseur d'accès;
* une topologie de site codée sur 16 bits (appelée '''Subnet ID'''). Ce champ permet de coder les numéros de sous réseau du site;
* un [[identifiant d'interface]] sur 64 bits (appelé '''Interface ID''') distinguant les différentes machines sur le lien.

==Structuration du prefixe global (GP)==

{{HorsTexte|Appréhender les tailles|France Télécom a obtenu du RIPE-NCC un <tt>/19</tt>. Si l'on enlève les troix premiers bits <tt>001</tt> désignant le plan d'adressage, il est donc possible d'avoir 216 opérateurs. Sachant qu'il y a 192 pays à l'ONU, ils pourraient chacun abriter 320 opérateurs de la taille de FT, chacun pouvant attribuer jusqu'à 229 <tt>/48</tt>, soit 536 870 912 sites}}

A part le préfixe <tt>2002::</tt> qui est est réservé au mécanisme de transition [[6to4]], cet espace est géré hierarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales ([http://www.iana.org/numbers/ RIR]) des préfixes actuellement de longueur 12 (cf. http://www.iana.org/assignments/ipv6-unicast-address-assignments) qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long. Le site http://www.sixxs.net/tools/grh/ donne en temps réel les allocations de préfixes par région, opérateur et pays.

Il est maintenant admis que le préfixe attribué par un opérateur à ses clients peut également être un <tt>/56</tt>. En effet, si l'on garde l'attribution de préfixe de longueur 48 pour les sites terminaux, et que l'on intègre les réseaux domotiques, les opérateurs peuvent justifier d'un besoin important d'adresses que les autorités régionales ne peuvent leur refuser.

{{ToDo|Ajouter comment obtenir un préfixe auprès de RIPE-NCC}}

==Structuration de l'identifiant de sous-réseau (SID)==

Il n'existe pas de règles pour allouer les identificateurs de sous-réseau au sein d'un site. Plusieurs techniques (non exclusives) peuvent être utilisées :

* numéroter de manière incrémentale les sous-réseaux: 0001, 0002, ... Cette technique est simple a mettre en œuvre dans des réseaux expérimentaux, mais elle peut conduire à un plan d'adressage à plat difficile à mémoriser. Elle peut être utilisée par exemple pour un sous-réseau dédié aux serveurs pour simplifier l'écriture et la mémorisation des adresses.
* utiliser le numéro de VLAN. Elle permet d'éviter de mémoriser plusieurs niveaux de numérotation.
* séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau suivant contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs :

{|
!Communauté !! 4bits !! width="50%"|8bits !! 4bits
|-style="background:silver"
| Infrastructure || 0 || colspan=2 | valeurs spécifiques
|-
| Tests || 1 || colspan=2 | valeurs spécifiques
|-style="background:silver"
| Tunnels || 6 || colspan=2 | allocation de /60 aux utilisateurs
|-
| Invités Wi-Fi || 8 || colspan=2 | valeurs spécifiques
|-style="background:silver"
| Personnels || A || Entité || Sous-Réseaux
|-
| Etudiants || E || Entité || Sous-Réseaux
|-style="background:silver"
| Autres (Start up, etc.) || F || colspan=2 | valeurs spécifiques
|+ Affectation des SID dans une université
|}

Ainsi, le préfixe:
* <tt>2001:DB8:1234::/52</tt> servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs seront prises dans cet espace;
* <tt>2001:DB8:1234:8000::/52</tt> servira pour le réseau Wi-Fi des invités. La manière dont sont gérés les 12 bits restants du SID ne sont pas spécifiés;
* <tt>2001:DB8:1234:E000::/52</tt> servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.

=== Adressage local : adresses lien-local ===

Les adresses de type lien-local (''link local use address'') sont des adresses dont la validité est restreinte à un lien, c'est-à-dire l'ensemble de interfaces directement connectées sans routeur intermédiaire comme par exemple des machines branchées sur un même réseau Ethernet, des machines reliées par une connexion PPP, ou des extrémités d'un tunnel. Les adresses lien-local sont configurées automatiquement à l'initialisation de l'interface et permettent la communication entre nœuds voisins. L'adresse est obtenue en concaténant le préfixe <tt>FE80::/64</tt> aux 64 bits de l'[[Identifiant d'interface|identifiant d'interface]]. L'identifiant d'interface est généralement basé sur l'adresse MAC. Cela ne pose pas de problème de respect de le vie privée car, contrairement aux adresses globales, les adresses lien-local ne sortent jamais du réseau où elles sont utilisées.

<tikz title="Adresses Lien-local">
% \draw (0, 3) node [right] {Link-Local Address:};
\draw (0,1.5) node [right, draw, shade, top color = yellow, minimum width=1.5cm, minimum height=1cm] {FE80};
\draw (1.5,1.5) node [right, draw, minimum width=4cm, minimum height=1cm] {0...0};
\draw (5.5,1.5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.7, 2.2) node {\tiny{10}};
\draw (3.5, 2.2) node {\tiny{54}};
\draw (8, 2.2) node {\tiny{64}};

\draw [snake=brace, mirror snake] (5.5, 0.8) -- (10.3, 0.8) node [below, midway] {\tiny{link address}} node [below = 8pt, midway] {\tiny{auto-configuration}} ;
</tikz>

Ces adresses sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins (''neighbor discovery'') et de découverte de routeurs (''router discovery''). Ce sont de nouveaux dispositifs, le premier supplantant en particulier le protocole ARP (''Address Resolution Protocol''), qui permettent à un réseau local de se configurer automatiquement (voir [[Découverte de voisins]]). Elles sont également largement utilisées par les protocoles de routage soit pour l'échange de données (cf. RIPng, OSPFv3), soit dans les tables de routage puisque le champ ''prochain routeur'' est toujours un équipement directement accessible sur le lien.
{{HorsTexte|Unicité sur le lien|Les adresses lien-local sont uniques à l'intérieur d'un lien. Le protocole de détection de duplication d'adresses (voir [[Configuration automatique#DAD|Détection d'adresse dupliquée]]) permet de s'en assurer. Par contre la duplication d'une adresse lien-local entre deux liens différents, ou entre deux interfaces d'un même nœud est autorisée.}}

Un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type lien-local.

Le fait que ces adresses aient une portée très faible les limite dans la pratique au cas où un démarrage automatique (''bootstrap'') est nécessaire. Leur usage ne doit pas être généralisé dans les applications classiques en régime stabilisé.

==== Portée de l'adresse (''scoped address'') ====

Une adresse lien-local (ou multicast) n'indique pas intrinsèquement l'interface de sortie, puisque toutes les interfaces partagent le même préfixe <tt>fe80::/10</tt>. Il faut donc indiquer de manière explicite sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère "%". Sous Linux, un argument, généralement <tt>-I</tt> permet de la désigner.

===Unique Local Address===

Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local Address''). Ces adresses sont destinées à une utilisation locale. Elles ne sont pas définies pour être routées dans l'Internet, mais seulement au sein d'une zone limitée telle qu'un site ou entre un nombre limité de sites. Les adresses uniques locales ont les caractéristiques suivantes :

* Prefixe ''globalement'' unique;
* Préfixe clairement défini facilitant le filtrage sur les routeurs de bordure;
* Permet l'interconnexion de sites sans générer de conflit d'adresse et sans nécessiter de renumérotation;
* Indépendantes des fournisseurs d'accès à l'Internet et ne nécessitent donc pas de connectivité;
* Pas de conflit en cas de routage par erreur en dehors d'un site;
* Aucune différence pour les applications, qui peuvent les considérer comme des adresses globales unicast standard.

<tikz title="Unique Local Addresses">
\clip (0, 0) rectangle (11,4);
% \draw[help lines] (0,0) grid (10,3);

% \draw (0, 3.6) node [right] {Unique Local IPv6 Unicast Addresses:};

\draw (0,2) node [right, draw, shade, top color = yellow, minimum width=1.5cm, minimum height=1cm] {FD};
\draw (1.5,2) node [right, draw, shade, top color = green, minimum width=3cm, minimum height=1cm] {Random Value};
\draw (4.5,2) node [right, draw, shade, top color = blue, minimum width=1cm, minimum height=1cm] {SID};
\draw (5.5,2) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.7, 2.7) node {\tiny{8}};
\draw (2.7, 2.7) node {\tiny{40}};
\draw (4.7, 2.7) node {\tiny{16}};
\draw (8, 2.7) node {\tiny{64}};

\draw [snake=brace, mirror snake] (0, 1.20) -- (4.5, 1.20) node [below, midway] {\tiny{private topology}} node [below = 8pt, midway] {\tiny{Not Routable in the Internet}} ;
\draw [snake=brace, mirror snake] (4.5, 1.20) -- (5.5, 1.20) node [below, midway] {\tiny{local topology}};
\draw [snake=brace, mirror snake] (5.5, 1.20) -- (10.3, 1.20) node [below, midway] {\tiny{link address}} ;
</tikz>

Les adresses uniques locales sont créées en utilisant un identifiant global (''Global ID'') généré pseudo-aléatoirement. Ces adresses suivent le format suivant :

* <tt>Prefix</tt> (7 bits) : <tt>FC00::/7</tt> préfixe identifiant les adresses IPv6 locales (''ULA'')
* <tt>L</tt> (1 bit) : Positionné à 1, le préfixe est assigné localement. La valeur 0 est réservée pour une utilisation future.
* <tt>Global ID</tt> (40 bits) : Identifiant global utilisé pour la création d'un préfixe ''unique'' (''Globally Unique Prefix'').
* <tt>Subnet ID</tt> (16 bits) : Identifiant d'un sous réseau à l'intérieur du site.
* <tt>Interface ID</tt> (64 bits) : L'indentifiant d'interface tel que défini dans [[Identifiant d'interface]].

Le site http://www.sixxs.net/tools/grh/ula/ permet de créer et d'enregistrer son adresse ULA à partir d'une adresse MAC.

= Structuration de l'identifiant d'interface (IID) =

Si initialement pour des raisons d'auto-configuration, l'identifiant d'interface devait toujours être dérivé de l'adresse de niveau 2, c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits:

* manuelle,
* basée sur l'adresse de niveau 2 de l'interface,
* aléatoire,
* cryptographique.

== Manuel ==
{{HorsTexte|Le resolveur DNS|Le résolveur DNS est le cas le plus flagrant; chaque machine sur le réseau doit être configurée avec l'adresse IPv6 du serveur DNS. En cas de changement de carte réseau, l'ensemble des machines du domaine devront être reconfigurées. Si l'on ne souhaite pas utiliser des protocoles de configuration automatique de type DHCPv6, il est préférable d'attribuer au résolveur DNS une adresse manuelle.}}
Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces, car dans ce cas l'adresse IPv6 est facilement mémorisable, et le serveur peut être accessible même si le DNS n'est pas actif.
Il existe plusieurs techniques plus ou moins mnémotechniques :
* incrémenter l'identifiant d'interface à chaque nouveau serveur créé

<tt>2001:DB8:1234:1::1</tt>
<tt>2001:DB8:1234:1::2</tt>
...

* reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple si un serveur a comme adresse IPv4 <tt>192.0.2.123</tt>, son adresse IPv6 sera :

<tt>2001:DB8:1234:1::7B</tt>
ou plus simplement
<tt>2001:DB8:1234:1::123</tt>

* reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à taper :

<tt>2001:DB8:1234:1::192.0.2.123</tt>

== Dérivé de l'adresse de l'interface==

L'avantage d'utiliser une adresse de niveau 2 pour construire un identifiant d'interface est que l'unicité de cette valeur est presque toujours assurée. En plus, cette valeur est stable tant que la carte réseau de la machine n'est pas changée. Par contre, ces valeurs sont difficilement mémorisables.

Les adresses lien-local sont construites en utilisant ce type d'identifiant. Par contre pour les adresses globales, il est conseillé de ne les utiliser que pour les machines client et de préférer les identifiants d'interface manuels pour les serveurs.

Ces identifiants d'interface étant stables dans le temps, à chaque fois qu'un individu change de réseau, il change de préfixe, mais garde le même identifiant d'interface. Ce dernier pourrait donc servir à tracer les déplacements d'un individu. Le risque est faible, car les cookies mis en place par les serveurs web sont bien plus efficaces, mais ils ne s'agit plus d'un problème réseau. Autre désavantage, comme les adresses MAC contiennent l'identification du matériel, il est possible d'indiquer à l'exterieur du réseau quel type de materiel est utilisé et donner des indications.

Si ces inconvénients sont jugés importants par l'entreprise, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement.

=== EUI-64 ===

<tikz title="Transformation d'une adresse MAC en identifiant d'interface">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{u}g}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (5, 1.5) node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};

</tikz>

L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (firewire) ou IEEE 802.15.4 (réseau de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64.

Il existe plusieurs méthodes pour construire l'identifiant :
{{HorsTexte|Ordre de transmission|L'ordre des bits ne doit pas porter à confusion. Dans la représentation numérique des valeurs, le premier bit transmis est le bit de poids faible, c'est-à-dire le bit de droite. Ainsi sur le support physique le bit <tt>g</tt>, puis le bit <tt>u</tt> puis les bits suivants sont transmis. }}

* Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure décrite figure Identificateur global IEEE EUI-64.
: Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802, identifient le constructeur et les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits <tt>u</tt> (septième bit du premier octet) et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :
:* <tt>u</tt> (Universel) vaut <tt>0</tt> si l'identifiant EUI-64 est universel,
:* <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g = 0</tt>), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g = 1</tt>), par exemple une adresse de multicast.

<tikz title="Identificateur d'interface dérivé d'une EUI-64">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (5, 1.5) node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};

</tikz>
* L'identifiant d'interface à 64 bits est dérivé de l'EUI-64 en inversant le bit <tt>u</tt> (cf. figure Identificateur d'interface dérivé d'une EUI-64). En effet, pour la construction des adresses IPv6, on a préféré utiliser <tt>1</tt> pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur <tt>0</tt> pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de <tt>1</tt>.

===MAC-48===

<tikz title="Transformation d'une adresse MAC en identifiant d'interface">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\only<2-> {
\draw (3, 4.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
\draw (4, 4.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (3, 4.25) rectangle+(3, 0.5);

\draw (0,4.5) node [right] {MAC-48};

\draw (6, 4.5) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (2, 3) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
\draw (3, 3) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 2.75) rectangle+(3, 0.5);

\draw (7, 3) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (6,4.5) -- (6, 4) -- (5, 3.5) -- (5, 3);
\draw (6,4) -- (7, 3.5) -- (7, 3);
\draw (3, 4.5) -- (3, 4) -- (2, 3.5) -- (2, 3);
\draw (9, 4.5) -- (9, 4) -- (10, 3.5) -- (10, 3);

\draw (5, 3) node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};

\draw (0,3) node [right] {EUI-64};
}

\only<3-> {

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (7, 1.5) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (5, 1.5) node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};

\draw (2,3) -- (2, 1.5);
\draw (10,3) -- (10, 1.5);
\draw (0,1.5) node [right] {IID};
}

</tikz>

* Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi). L'adresse est tout d'abord convertie en EUI-64, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure ci-contre illustre ce processus.

===Cas Particuliers===
* Si une interface possède une adresse locale unique sur le lien, mais non universelle (par exemple le format d'adresse IEEE 802 sur 2 octets ou une adresse sur un réseau Appletalk), l'identifiant d'interface est construit à partir de cette adresse en rajoutant des 0 en tête pour atteindre 64 bits.

{{HorsTexte|Erreur de l'IETF|À noter que l'IETF s'est trompée quand elle a défini l'algorithme de conversion. En effet, l'ajout de la valeur <tt>0xFFFE</tt> concerne les EUI-48, c'est-à-dire des identifiants, alors qu'Ethernet utilise des MAC-48, c'est-à-dire des adresses (ils servent à transporter des trames vers le bon destinataire). La bonne valeur aurait été <tt>0xFFFF</tt>. Mais cette erreur n'a aucune conséquence pour l'identification des équipements, elle n'a donc pas été corrigée par la suite.}}

* Si une interface ne possède aucune adresse (par exemple l'interface utilisée pour les liaisons PPP), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle ou bien une génération aléatoire, avec le bit u positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, et devra être résolu manuellement.

== Valeur aléatoire ==

L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pourrait poser des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur, qui même s'il se déplace de réseau en réseau garde ce même identifiant. Il serait alors possible de traquer un individu utilisant un portable, chez lui, au bureau, lors de ses déplacements. Ce problème est similaire à l'identificateur placé dans les processeurs Pentium III.

[[image:Windows7-IIDalea.png|500px|right]]

Pour couper court à toute menace de boycott d'un protocole qui « menacerait la vie privée », il a été proposé d'autres algorithmes de construction d'un identifiant d'interface basé sur des tirages aléatoires (voir RFC 3041). Un utilisateur particulièrement méfiant pourrait valider ces mécanismes. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme comme MD5 à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.

Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globale. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (i.e. les applications serveur). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours et sert aux applications client. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur Linux et les système d'exploitation BSD comme Mac OS.

Bien entendu pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse ou que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit impossible.

En contre partie, il est plus difficile à un administrateur réseau de filtrer les machines puisque celles-ci changent périodiquement d'adresses.

== Cryptographique ==

{{HorsTexte|Encore un sujet de recherche|L'usage de ces adresses n'est pas encore généralisé. Shim6 pour la gestion de la multi-domiciliation ou SEND pour sécuriser la découverte de voisins y ont recours.}}
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.

=Adresses Multicast=
{{HorsTexte|Portée et portée|Il ne faut pas confondre la portée d'une adresse link-local ou multicast qui désigne l'interface par laquelle sera émis le paquet et la portée d'un groupe multicast qui désigné l'étendue de la couverture}}
Cette section décrit brièvement le système d'adressage multicast IPv6 et ne s'intéresse qu'aux adresses utilisées localement par les protocoles directement liés à IPv6 (Découverte de voisins, DHCPv6,...). Pour plus de détails sur le multicast en général, se reporter au chapitre [[Multicast]]. La figure Structure de l'adresse IPv6 Multicast donne le format de l'adresse IPv6 de multicast décrite dans le RFC 3513.

<tikz title="Structure de l'adresse IPv6 Multicast">
\clip (0, 1) rectangle (11,4);
% \draw[help lines] (0,0) grid (10,4 );

% \draw (0, 3.6) node [right] {Generic Format:};

\draw (0,2) node [right, draw, shade, top color = yellow, minimum width=2cm, minimum height=1cm] {FF};
\draw (2,2) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tiny{\tt{xRPT}}};
\draw (3,2) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tiny{scope}};
\draw (4,2) node [right, draw, shade, top color = black!50, minimum width=6cm, minimum height=1cm] {Group ID};

\draw (1, 2.7) node {\tiny{8}};
\draw (2.5, 2.7) node {\tiny{4}};
\draw (3.5, 2.7) node {\tiny{4}};
\draw (7, 2.7) node {\tiny{112}};

</tikz>

Les adresses multicast IPv6 sont dérivées du préfixe <tt>FF00::/8</tt>. Le champ drapeaux de 4 bits est défini de la manière suivante :

* Seul le bit <tt>T</tt> (comme ''Transient'') du champ drapeaux est initialement décrit dans le RFC 3513. La valeur <tt>0</tt> indique une adresse multicast bien connue gérée par une autorité. La valeur <tt>1</tt> indique une valeur temporaire.
* Les bits <tt>P</tt> et <tt>R</tt> sont décrits dans le RFC 3306 et le draft Internet sur embedded-RP (RFC 3956).
* Le bit de poids fort du champ drapeaux n'est pas encore attribué.

Le champ drapeaux permet de définir plusieurs types d'adresses multicast IPv6 qui seront décrits dans les sections suivantes.

Le champ scope de l'adresse multicast IPv6 permet d'en limiter la portée (''scope'' en anglais). En IPv4, la portée d'un paquet est limitée par le champ TTL (''Time To Live''), de même des préfixes peuvent être définis pour identifier des adresses à portée réduite. Les valeurs suivantes sont définies dans la RFC 2373 :

* 1 - node-local : Les paquets ne sortent pas de la machine, cette adresse sert pour la communication entre les applications.
* 2 - link-local : La portée se limite au réseau local, les paquets ne peuvent pas traverser les routeurs multicast. Cette valeur est utilisée en particulier par le protocole de découverte des voisins.
* 3 - subnet-local : Ce type n'est pas officiellement défini, mais se retrouve dans certains documents. Il permet de faire la différence entre un lien physique et un lien logique (regroupement de plusieurs liens physiques) partageant le même préfixe IPv6.
* 4 - admin-local
* 5 - site-local
* 8 - organisation-local
* E - global
* Les portées 0 et F sont réservées.

http://www.iana.org/assignments/ipv6-multicast-addresses donne les adresses multicast définies. Le tableau ci-dessous liste les plus utilisées :

{|
!Adresse multicast !! usage
|-style="background:silver"
| FF01::1 || All Nodes Address
|-
| FF01::2 || All Routers Address
|-style="background:silver"
| FF02::1 || All Nodes Address
|-
| FF02::2 || All Routers Address
|-style="background:silver"
| FF02::5 || OSPFIGP
|-
| FF02::6 || OSPFIGP Designated Routers
|-style="background:silver"
| FF02::9 || RIP Routers
|-
| FF02::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-style="background:silver"
| FF02::1:2 || All-dhcp-agents
|-
| FF03::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-style="background:silver"
| FF04::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-
| FF05::2 || All Routers Address
|-style="background:silver"
| FF05::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-
| FF05::1:3 || All-dhcp-servers
|-style="background:silver"
| FF0X::101 || Network Time Protocol (NTP)
|}

==Adressage Multicast Sollicité==

IPv6 interdit l'utilisation de la diffusion généralisée (Broadcast) lorsque le Multicast est disponible. Ainsi les protocoles comme Neighbor Discovery, chargé de faire le lien entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse de Multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>FF02::1</tt> (tous les équipements sur le lien, l'utilisation des adresses de multicast sollicité permet de réduire considérablement le nombre d'équipements qui recevront la requête.

<tikz title="Construction de l'adresse de Multicast sollicité">
\clip (0, 0) rectangle (10,4);
%\draw[help lines] (0,0) grid (10,4 );

\draw (2, 3.75) node (mac) [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{01-02-03-04-05-06}}};

\draw (0, 2.75) node (LL) [right, draw, shade, top color = green!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{FE80::0102:03FF:FE04:0506}}};

\draw (4, 2.75) node (GP) [right, draw, shade, top color = green!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{GP:0102:03FF:FE04:0506}}};

\draw [->] (mac) -- (LL);
\draw [->] (mac) -- (GP);

\draw (8, 2.75) node (manuel) [right, draw, shade, top color = green!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{GP::1}}};

\draw (2.5, 1.75) node (MS1) [right, draw, shade, top color = red!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{FF02::1:FF04:0506}}};
\draw [->] (LL) -- (MS1);
\draw [->] (GP) -- (MS1);

\draw (7.4, 1.75) node (MS2) [right, draw, shade, top color = red!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{FF02::1:FF00:0001}}};
\draw [->] (manuel) -- (MS2);

\draw (2.5, 0.75) node (mac2) [right, draw, shade, top color = blue!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{33-33-FF-04-05-06}}};
\draw [->] (MS1) -- (mac2);

\draw (7.4, 0.75) node (mac3) [right, draw, shade, top color = blue!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{33-33-FF-00-00-01}}};
\draw [->] (MS2) -- (mac3);
</tikz>

La figure Construction de l'adresse de Multicast sollicité montre comment l'on passe d'une adresse IPv6 unicast à une adresse de multicast sollicité. Il s'agit de prendre les 3 derniers octets de l'adresse unicast que l'on concatène avec le préfixe IPv6 multicast <tt>FF02::1:FF00:0/104</tt>.

Dans l'exemple, les deux adresses dérivant d'une adresse MAC conduisent à la même adresse de multicast sollicité, tandis que la configuration manuelle d'une interface conduit à la construction d'une autre adresse de multicast sollicité. On peut noter que le risque que deux machines sur un lien aient la même adresse de multicast sollicité est très faible. Pour celles dérivant d'une adresse MAC, il faudrait que les 3 derniers octets soient identiques, ce qui est impossible chez un même constructeur et la probabilité d'avoir, sur un même lien, des cartes de deux constructeurs différents se terminant par les mêmes 3 derniers octets est très faible. Pour la numérotation manuelle des interfaces, une machine ayant l'adresse <tt>GP:::0100:0001</tt> conduirait à construire la même adresse de multicast sollicité <tt>FF02::1:FF00:0001</tt>, mais cette numérotation manuelle des interfaces n'est pas logique.

{{HorsTexte|Sollicitation des voisins|L'algorithme de découverte des adresses de niveau 3 des voisins (inclus dans Neighbor Discovery) fonctionne de la manière suivante. La machine qui recherche un voisin dont elle connait l'adresse IPv6, effectue l'algorithme décrit précédemment. Elle émet la requête en utilisant l'adresse MAC obtenue. Seule la machine qui possède cette adresse est abonnée à ce groupe, elle sera donc la seule à traiter la requête et à y répondre.}}

L'exemple se poursuit par la transformation de l'adresse de Multicast au niveau IPv6 en adresse de multicast de niveau 2. Elle est très spécifique à la technologie et à la manière dont est mis en œuvre le multicast au niveau 2. Pour les réseaux Ethernet (et dérivés comme le Wi-Fi), les 4 derniers octets de l'adresse multicast sollicité sont ajoutés au préfixe <tt>33-33</tt>.
{{Suivi| Introduction|Introduction | AdressageBis-MeO|Mises en Oeuvre}}

AdressageBis-Questionnaire

2011-11-02T17:01:46Z

Ltoutain: /* Questions */

{{Suivi|AdressageBis-Références|Références|Table_des_matières|Fin du chapitre}}

= Questions =

<quiz display=simple>
{Quelle affirmation est vraie pour l'adresse 2001:660:1:0000:1000:0000:0000:5678 .
|type="()"}
- Le préfixe 2001:660:1000::/40 est contenu dans cette adresse.
+ Elle peut être écrite 2001:660:0001:0000:1::5678
- Elle peut être écrite 2001:660:1::1000::5678
- Le préfixe 2001:660::/48 est contenu dans cette adresse.

{Une adresse IPv6 étant quatre fois plus longue qu'une adresse IPv4 permet:
|type="()"}
- d'adresser quatre fois plus de machine qu'IPv4
- de ne jamais renuméroter les réseaux
+ d'avoir un plan d'adressage quasi-illimité
- de donner une adresse a des équipements qui peuvent être potentiellement mis en réseau.

{Un ordinateur donne le résultat suivant pour la commande <tt>ifconfig</tt>

lo0: flags=1000849;UP,LOOPBACK,RUNNING,MULTICAST,IPv4; mtu 8232 index 1
inet 127.0.0.1 netmask ff000000

lo0: flags=2000849;UP,LOOPBACK,RUNNING,MULTICAST,IPv6; mtu 8252 index 1
inet6 ::1/128

eri0: flags=1000843;UP,BROADCAST,RUNNING,MULTICAST,IPv4; mtu 1500 index 2
inet 193.52.74.15 netmask ffffff00 broadcast 193.52.74.255

eri0: flags=2000841;UP,RUNNING,MULTICAST,IPv6; mtu 1500 index 2
inet6 fe80::203:baff:fe14:97c8/10

eri1: flags=2080841;UP,RUNNING,MULTICAST,ADDRCONF,IPv6; mtu 1500 index 2
inet6 2001:660:7301:3193:203:baff:fe14:97c8/64

eri2: flags=2000841;UP,RUNNING,MULTICAST,IPv6; mtu 1500 index 2
inet6 2001:660:7301:3193::4/64
| type="()"}
- ::1/128 est une adresse lien-local
- l'interface de loopback est différente en IPv4 et IPv6
+ l'ordinateur a deux adresses globales
- sur cet ordinateur, les interfaces lien-locale n'ont pas besoin d'être scopée

{Le plan d'adressage CIDR permet:
|type="()"}
- d'utiliser la place des classes E
+ de minimiser la taille du bloc d'adresse demandé et de coller aux besoins de la compagnie
- de coder la longueur du préfixe dans les 32 bit de l'adresse
- d'attribuer des adresses aux clients finaux sans passer par les opérateurs.

{Toutes les adresses IPv6 sont divisées en trois parties (GP, SID, IID)
|type="()"}
- Oui
- Non, seulement les adresses lien-locale et globale sont divisées en trois parties
- Non, les adresses anycast ne sont pas divisées en trois parties
+ Non, ce schéma est juste pour les adresses globale et ULA

{Avec CIDR, la longueur du préfixe doit être ajoutée au préfixe:
|type="()"}
- Non, la longueur du préfixe est stockée dans les premiers bits de l'adresse
- Non, la longueur du préfixe est stockée dans les derniers bits de l'adresse
- Oui, en indiquant le nombre de bits restant
+ Oui, en indiquant le nombre de bits assigné dans le préfixe

{Quand l'espace d'adressage IPv4 sera épuisé. La taille des tables de routages du cœur du réseau:
|type="()"}
- diminueront
- resteront a peu près stable
+ augmenteront
- disparaitront

{Sur cet équipement :
<tt>RouterB25#sh ipv6 interface
GigabitEthernet0/0 is up, line protocol is up
IPv6 is enabled,
link-local address is FE80::219:56FF:FE49:8E98
Global unicast address(es): 2001:660:7300:1009:38:0:6:5173, subnet is 2001:660:7300:1009::/64
Joined group address(es):
FF02::1
FF02::2
FF02::9
FF02::1:FF06:5173
FF02::1:FF49:8E98 </tt>
|type="()"}
+ l'IID de l'adresse globale est attribué manuellement
- l'IID de l'adresse lien-local est généré aléatoirement
- l'adresse globale est FF02::1:FF06:5173
- l'interface appartient a un seul groupe multicast sollicitié

{Quelle est la longueur d'un préfixe lien-local ?
|type="()"}
- FE80::/64
+ FE80::/10
- FE80::/16
- FE80::/48

{Les adresses IPv4 peuvent être incluses dans les adresses IPv6?
|type="()"}
- Oui seulement pour 6to4
- Oui, si les adresses IPv4 dérivent de la classe E
+ Oui, une adresse IPv6 peut contenir une ou plusieurs adresses IPv4
- non, elles sont incompatibles

</quiz>
{{Suivi|AdressageBis-Références|Références|Table_des_matières|Fin du chapitre}}

IntegrationBis

2011-07-04T13:41:28Z

Ltoutain: New page: =Pourquoi intégrer IPv6 = =Les 6 différents scenarios génériques = =Classes d'outils= * Tunnels * Traduction * Proxy =Scénarios= * ''introduire la méthodologie/démarche d'inté...

=Pourquoi intégrer IPv6 =

=Les 6 différents scenarios génériques =

=Classes d'outils=

* Tunnels
* Traduction
* Proxy

=Scénarios=

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

=Opérateur=
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

=Fournisseur d'accès=
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

= Entreprise/Réseau privé administré =
* Réseau
** Préparation (formation du personnel, niveau de formation, documentation technique de l'entreprise)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6
** Outils de test de la connectivité
*** looking glass
*** ipv6-test.com

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

= ADSL : Particulier / TPE Réseau privé non administré =
* Comment obtenir une connectivité et un préfixe
** Par l'opérateur
** Tunnel broker
** Softwires H&S
* Compatibilité des équipements
* Approche double pile totale
** Problèmes liés à la gestion de la double pile
* Gestion de la sécurité
** UPnP v6
* Comment publier un service
** DNS, configuration du FW.

recherche:
* Distribution du préfixe dans un réseau routé : TRILL, IEEE 802.1ad, FUN

= Hébergeurs de services=

* Connectivité et transit (PI ou PA)
* DNS
* Plan d'adressage / Quoi allouer aux clients
* Règles d'usage / Sécurité

* Comment v6fier un service v4.

= Nouveaux services ?=
* Domotique
* IoT
** Smart Grid
** M2M
** ITS

=Ne pas traiter le cas de l'opérateur mobile (en interne)=

TdMbis

2011-07-04T13:39:58Z

Ltoutain: /* Intégration d'IPv6 et des applications (Bruno Stévant) */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

Recherche

Résoudre le problème du MH

* LISP
* Shim6/SCTP/MPTCP
* HIP

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= [[IntegrationBis|Intégration d'IPv6 et des applications (Bruno Stévant)]] =

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T13:39:26Z

Ltoutain: /* Intégration d'IPv6 et des applications (Bruno Stévant) */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

Recherche

Résoudre le problème du MH

* LISP
* Shim6/SCTP/MPTCP
* HIP

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T13:37:23Z

Ltoutain: /* Intégration d'IPv6 et des applications (Bruno Stévant) */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

Recherche

Résoudre le problème du MH

* LISP
* Shim6/SCTP/MPTCP
* HIP

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** Préparation (formation du personnel, niveau de formation, documentation technique de l'entreprise)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6
** Outils de test de la connectivité
*** looking glass
*** ipv6-test.com

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===
* Comment obtenir une connectivité et un préfixe
** Par l'opérateur
** Tunnel broker
** Softwires H&S
* Compatibilité des équipements
* Approche double pile totale
** Problèmes liés à la gestion de la double pile
* Gestion de la sécurité
** UPnP v6
* Comment publier un service
** DNS, configuration du FW.

recherche:
* Distribution du préfixe dans un réseau routé : TRILL, IEEE 802.1ad, FUN

=== Hébergeurs de services===

* Connectivité et transit (PI ou PA)
* DNS
* Plan d'adressage / Quoi allouer aux clients
* Règles d'usage / Sécurité

* Comment v6fier un service v4.

=== Nouveaux services ?===
* Domotique
* IoT
** Smart Grid
** M2M
** ITS

==Ne pas traiter le cas de l'opérateur mobile (en interne)==

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T13:26:40Z

Ltoutain: /* Routage (Alain Bidaud) */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

Recherche

Résoudre le problème du MH

* LISP
* Shim6/SCTP/MPTCP
* HIP

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** Préparation (formation du personnel, niveau de formation, documentation technique de l'entreprise)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6
** Outils de test de la connectivité
*** looking glass
*** ipv6-test.com

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===
* Comment obtenir une connectivité et un préfixe
** Par l'opérateur
** Tunnel broker
** Softwires H&S
* Compatibilité des équipements
* Approche double pile totale
** Problèmes liés à la gestion de la double pile
* Gestion de la sécurité
** UPnP v6
* Comment publier un service
** DNS, configuration du FW.

recherche:
* Distribution du préfixe dans un réseau routé : TRILL, IEEE 802.1ad, FUN

=== Hébergeurs de services===

* Connectivité et transit (PI ou PA)
* DNS
* Plan d'adressage / Quoi allouer aux clients
* Règles d'usage / Sécurité

* Comment v6fier un service v4.

=== Nouveaux services ?===
* Domotique
* IoT
** Smart Grid
** M2M
** ITS

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T13:25:12Z

Ltoutain: /* Routage (Alain Bidaud) */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

Recherche

* LISP

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** Préparation (formation du personnel, niveau de formation, documentation technique de l'entreprise)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6
** Outils de test de la connectivité
*** looking glass
*** ipv6-test.com

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===
* Comment obtenir une connectivité et un préfixe
** Par l'opérateur
** Tunnel broker
** Softwires H&S
* Compatibilité des équipements
* Approche double pile totale
** Problèmes liés à la gestion de la double pile
* Gestion de la sécurité
** UPnP v6
* Comment publier un service
** DNS, configuration du FW.

recherche:
* Distribution du préfixe dans un réseau routé : TRILL, IEEE 802.1ad, FUN

=== Hébergeurs de services===

* Connectivité et transit (PI ou PA)
* DNS
* Plan d'adressage / Quoi allouer aux clients
* Règles d'usage / Sécurité

* Comment v6fier un service v4.

=== Nouveaux services ?===
* Domotique
* IoT
** Smart Grid
** M2M
** ITS

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T13:22:54Z

Ltoutain: /* Nouveaux services ? */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** Préparation (formation du personnel, niveau de formation, documentation technique de l'entreprise)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6
** Outils de test de la connectivité
*** looking glass
*** ipv6-test.com

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===
* Comment obtenir une connectivité et un préfixe
** Par l'opérateur
** Tunnel broker
** Softwires H&S
* Compatibilité des équipements
* Approche double pile totale
** Problèmes liés à la gestion de la double pile
* Gestion de la sécurité
** UPnP v6
* Comment publier un service
** DNS, configuration du FW.

recherche:
* Distribution du préfixe dans un réseau routé : TRILL, IEEE 802.1ad, FUN

=== Hébergeurs de services===

* Connectivité et transit (PI ou PA)
* DNS
* Plan d'adressage / Quoi allouer aux clients
* Règles d'usage / Sécurité

* Comment v6fier un service v4.

=== Nouveaux services ?===
* Domotique
* IoT
** Smart Grid
** M2M
** ITS

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T13:20:43Z

Ltoutain: /* Cloud */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** Préparation (formation du personnel, niveau de formation, documentation technique de l'entreprise)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6
** Outils de test de la connectivité
*** looking glass
*** ipv6-test.com

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===
* Comment obtenir une connectivité et un préfixe
** Par l'opérateur
** Tunnel broker
** Softwires H&S
* Compatibilité des équipements
* Approche double pile totale
** Problèmes liés à la gestion de la double pile
* Gestion de la sécurité
** UPnP v6
* Comment publier un service
** DNS, configuration du FW.

recherche:
* Distribution du préfixe dans un réseau routé : TRILL, IEEE 802.1ad, FUN

=== Hébergeurs de services===

* Connectivité et transit (PI ou PA)
* DNS
* Plan d'adressage / Quoi allouer aux clients
* Règles d'usage / Sécurité

* Comment v6fier un service v4.

=== Nouveaux services ?===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T13:18:09Z

Ltoutain: /* Hébergeurs de services */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** Préparation (formation du personnel, niveau de formation, documentation technique de l'entreprise)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6
** Outils de test de la connectivité
*** looking glass
*** ipv6-test.com

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===
* Comment obtenir une connectivité et un préfixe
** Par l'opérateur
** Tunnel broker
** Softwires H&S
* Compatibilité des équipements
* Approche double pile totale
** Problèmes liés à la gestion de la double pile
* Gestion de la sécurité
** UPnP v6
* Comment publier un service
** DNS, configuration du FW.

recherche:
* Distribution du préfixe dans un réseau routé : TRILL, IEEE 802.1ad, FUN

=== Hébergeurs de services===

* Connectivité et transit (PI ou PA)
* DNS
* Plan d'adressage / Quoi allouer aux clients
* Règles d'usage / Sécurité

* Comment v6fier un service v4.

=== Cloud===

=== Nouveaux services ?===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T13:11:03Z

Ltoutain: /* Intégration d'IPv6 et des applications (Bruno Stévant) */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** Préparation (formation du personnel, niveau de formation, documentation technique de l'entreprise)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6
** Outils de test de la connectivité
*** looking glass
*** ipv6-test.com

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===
* Comment obtenir une connectivité et un préfixe
** Par l'opérateur
** Tunnel broker
** Softwires H&S
* Compatibilité des équipements
* Approche double pile totale
** Problèmes liés à la gestion de la double pile
* Gestion de la sécurité
** UPnP v6
* Comment publier un service
** DNS, configuration du FW.

recherche:
* Distribution du préfixe dans un réseau routé : TRILL, IEEE 802.1ad, FUN

=== Hébergeurs de services===

=== Cloud===

=== Nouveaux services ?===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T13:07:47Z

Ltoutain: /* ADSL : Particulier / TPE Réseau privé non administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** Préparation (formation du personnel, niveau de formation, documentation technique de l'entreprise)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6
** Outils de test de la connectivité
*** looking glass
*** ipv6-test.com

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===
* Comment obtenir une connectivité et un préfixe
** Par l'opérateur
** Tunnel broker
** Softwires H&S
* Compatibilité des équipements
* Approche double pile totale
** Problèmes liés à la gestion de la double pile
* Gestion de la sécurité
** UPnP v6
* Comment publier un service
** DNS, configuration du FW.

recherche:
* Distribution du préfixe dans un réseau routé : TRILL, IEEE 802.1ad, FUN

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T13:05:39Z

Ltoutain: /* ADSL : Particulier / TPE Réseau privé non administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** Préparation (formation du personnel, niveau de formation, documentation technique de l'entreprise)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6
** Outils de test de la connectivité
*** looking glass
*** ipv6-test.com

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===
* Comment obtenir une connectivité et un préfixe
** Par l'opérateur
** Tunnel broker
** Softwires H&S
* Compatibilité des équipements
* Approche double pile totale
** Problèmes liés à la gestion de la double pile
* Gestion de la sécurité
** UPnP v6

recherche:
* Distribution du préfixe dans un réseau routé : TRILL, IEEE 802.1ad, FUN

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T13:02:38Z

Ltoutain: /* ADSL : Particulier / TPE Réseau privé non administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** Préparation (formation du personnel, niveau de formation, documentation technique de l'entreprise)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6
** Outils de test de la connectivité
*** looking glass
*** ipv6-test.com

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===
* Comment obtenir une connectivité et un préfixe
** Par l'opérateur
** Tunnel broker
** Softwires H&S
* Compatibilité des équipements
* Approche double pile totale
** Problèmes liés à la gestion de la double pile
* UPnP v6

recherche:
* Distribution du préfixe dans un réseau routé : TRILL, IEEE 802.1ad, FUN

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:58:23Z

Ltoutain: /* ADSL : Particulier / TPE Réseau privé non administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** Préparation (formation du personnel, niveau de formation, documentation technique de l'entreprise)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6
** Outils de test de la connectivité
*** looking glass
*** ipv6-test.com

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===
* Comment obtenir une connectivité et un préfixe
** Par l'opérateur
** Tunnel broker
* Approche double pile totale
** Problèmes liés à la gestion de la double pile
* UPnP v6

recherche:
* Distribution du préfixe dans un réseau routé : TRILL, IEEE 802.1ad, FUN

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:48:55Z

Ltoutain: /* Entreprise/Réseau privé administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** Préparation (formation du personnel, niveau de formation, documentation technique de l'entreprise)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6
** Outils de test de la connectivité
*** looking glass
*** ipv6-test.com

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===

* Problèmes liés à la gestion de la double pile

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:41:50Z

Ltoutain: /* ADSL : Particulier / TPE Réseau privé non administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** Préparation (formation du personnel, niveau de formation, documentation technique de l'entreprise)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===

* Problèmes liés à la gestion de la double pile

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:38:42Z

Ltoutain: /* Entreprise/Réseau privé administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** Préparation (formation du personnel, niveau de formation, documentation technique de l'entreprise)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:37:48Z

Ltoutain: /* Entreprise/Réseau privé administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** Préparation (formation du personnel, niveau de formation)
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage et placement des fonctionnalités
*** LoWPAN ?
*** Restrictions d'usage/sécurité
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6

* Approches
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG (reverse proxy), NAT64/DNS64, Load Balancer
** Firewall/IDS
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:31:36Z

Ltoutain: /* Entreprise/Réseau privé administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage (voir RIPE)
*** LoWPAN
*** Restrictions d'usage
** Appel d'offre
*** Limite des équipements
*** Test des équipements
** Supervision/Gestion des adresses
** Multi-Homing
** ULA/NPTv6

* Approche
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG, NAT64/DNS64, Load Balancer
** Firewall
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** VoIP

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:27:08Z

Ltoutain: /* Entreprise/Réseau privé administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage (voir RIPE)
*** Restrictions d'usage
** Appel d'offre
*** Test des équipements
** Multi-Homing
** ULA/NPTv6

* Approche
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG, NAT64/DNS64, Load Balancer
** Firewall
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** ToIP
**

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:26:14Z

Ltoutain: /* Entreprise/Réseau privé administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage (voir RIPE)
*** Restrictions d'usage
** Appel d'offre
*** Test des équipements
** Multi-Homing
** ULA/NPTv6

* Approche
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG, NAT64/DNS64, Load Balancer
** Firewall
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** ToIP
**

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:25:48Z

Ltoutain: /* Entreprise/Réseau privé administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage (voir RIPE)
*** Restrictions d'usage
** Appel d'offre
*** Test des équipements
** Multi-Homing
** ULA

* Approche
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG, NAT64/DNS64, Load Balancer
** Firewall
** coût de la maintenance IPv4 dans le futur, migration des applications métiers.

* Applications
** mail: antispam
** ToIP
**

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:21:19Z

Ltoutain: /* Entreprise/Réseau privé administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage (voir RIPE)
*** Restrictions d'usage
** Appel d'offre
*** Test des équipements

* Approche
** ne pas tout v6fier à fois, commencer interface publique (DNS, http(s), mail, vpn)
** ALG, NAT64/DNS64, Load Balancer
** Firewall

* Applications
** mail: antispam
** ToIP
**

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:19:02Z

Ltoutain: /* Entreprise/Réseau privé administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage (voir RIPE)
*** Restrictions d'usage
** Appel d'offre
*** Test des équipements

* Approche
** ne pas tout v6fier à fois, interface publique.
** ALG, NAT64/DNS64, Load Balancer
** Firewall

* Applications
** mail: antispam
** ToIP

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:17:18Z

Ltoutain: /* Entreprise/Réseau privé administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage (voir RIPE)
*** Restriction d'usage
** Appel d'offre
*** Test des équipements

* Approche
** ne pas tout v6fier à fois, interface publique.
** ALG, NAT64/DNS64, Load Balancer

* Applications
** mail: antispam

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:14:04Z

Ltoutain: /* Entreprise/Réseau privé administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage (voir RIPE)
*** Restriction d'usage
** Appel d'offre
*** Test des équipements

* Applications
** mail: antispam

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:10:56Z

Ltoutain: /* Fournisseur d'accès */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage (préfixe d'interco dans l'espace du client ?)
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage (voir RIPE)
*** Restriction d'usage
** Appel d'offre
*** Test des équipements

* Applications
** mail: antispam

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:09:42Z

Ltoutain: /* Fournisseur d'accès */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** Règles d'adressage
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage (voir RIPE)
*** Restriction d'usage
** Appel d'offre
*** Test des équipements

* Applications
** mail: antispam

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T12:08:05Z

Ltoutain: /* Entreprise/Réseau privé administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage (voir RIPE)
*** Restriction d'usage
** Appel d'offre
*** Test des équipements

* Applications
** mail: antispam

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T11:52:45Z

Ltoutain: /* Entreprise/Réseau privé administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage (voire RIPE)

* Applications
** mail: antispam

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T11:52:20Z

Ltoutain: /* Entreprise/Réseau privé administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** comment obtenir son prefixe
*** LIR
*** Tunnel Broker
*** Eviter 6to4 et TEREDO
** Plan d'adressage

* Applications
** mail: antispam

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]

TdMbis

2011-07-04T11:51:11Z

Ltoutain: /* Entreprise/Réseau privé administré */

=Table des matières=

==Actions==

*Relecture:
** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage)

* Court terme -> 28/2
** passer les chapitres IPv6, ND, Nommage en production
** Faire un plan pour Routage, Intégration, Sécurité supervision
** Ajuster le chapitre auto-conf
** Question Luc Saccavini sur participation à l'historique: OK
** Question Pierre Françon sur gestion du chapitre sécurité: Non

* Moyen Terme -> 14/7
** Revoir DHCPv6
** Thanh Luu: récuperer des adresses au RIPE NCC
** Revoir les exemples des premiers chapitres
** Remettre a jour : Support de transmission (6LoWPAN)
** Contenu Routage, Intégration, Sécurité, Supervision

* Long terme
** Mobilité

Fixer une reunion en Mars.

----
''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =

''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Protocoles réseau et transport (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= Configuration automatique et contrôle (Laurent Toutain) =
''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme''

= [[NommageBis|Nommage]] (Mohsen Souissi) =

= Supports de transmission (Laurent Toutain) =
= Routage (Alain Bidaud) =

A discuter dans le groupe des rédacteurs :

Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)

Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait

- une première partie destinée aux ISP

- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)

Ajouter RPSLng (déclaration des politiques de routage dans les IRR)

Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)

= Multicast =
* [[Adressage multicast]]
* [[Le multicast IPv6 sur le lien-local]]
* [[PIM]]
* [[Multicast IPv6 inter-domaine]]
* [[Déploiement du multicast]]
* [[Coexistence avec le multicast IPv4]]
* [[Etude pratique du déploiement du multicast IPv6]]
* [[Exemples de configuration dans un routeur Cisco]]

= Sécurité (Pierre Françon ?) =

= [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =

= Intégration d'IPv6 et des applications (Bruno Stévant) =

==Pourquoi intégrer IPv6 ==

==Les 6 différents scenarios génériques ==

==Classes d'outils==

* Tunnels
* Traduction
* Proxy

==Scénarios==

* ''introduire la méthodologie/démarche d'intégration''
* Type de mécanismes
* Outils

===Opérateur===
* Forwarding => Dual Stack, 6PE, L2VPN, 6VPN dans le coeur
* Peering: 1 ou 2 peering
** Mettre des exemples de configuration

===Fournisseur d'accès===
* Comment obtenir un prefixe des registries
* Attribution des préfixes
** 6rd, CGN, 4rd, Softwires H&S
** ADSL, *G
** (''entreprise'')
* Aspects légaux

=== Entreprise/Réseau privé administré ===
* Réseau
** comment obtenir son prefixe

* Application
** mail: antispam

=== ADSL : Particulier / TPE Réseau privé non administré ===

=== Nouveaux services ?===

=== Cloud===

=== Hébergeurs de services===

= [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =

= Supervision (Jean-Jacques Broussat) =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

----

Old Stuff: chapters removed from the previous edition.

= Adressage =
*[[Adressage|Généralités]]
*[[Plans d'adressage]]
*[[Unicast Global|Adresses Globales]]
*[[Lien-local|Adresses Lien-local]]
*[[Identifiant d'interface]]
*[[Site-local]]
*[[Autres types d'adresses]]
*[[Exemple Unicast|Exemple d'utilisation des adresses unicast]]
*[[Anycast]]

= Protocoles réseau et transport =
* [[IPv6]]
**Champs particuliers
***[[Classe de trafic]]
***[[Identificateur de flux]]
**[[Justification des extensions]]
**[[Les extensions]]
**[[Exemples d'extensions]]
**[[Checksum au niveau transport]]
*[[ICMPv6]]
*[[Protocoles de Niveau 4]]

= Configuration automatique et contrôle =
* [[Découverte de voisins]]
** [[Exemples de découverte de voisins]]
* [[Configuration automatique]]
** [[Exemples de configuration sans état]]
* [[Configuration avec état :DHCPv6]]
* [[Renumérotation des routeurs]]
* [[Mécanisme de découverte du PMTU]]

= [[Nommage]] =
* [[Nommage direct : du nom vers les adresses]]
* [[Nommage inverse : de l'adresse vers les noms]]
* [[Logiciels DNS supportant IPv6 et configurations]]
* [[Les solutions expérimentales A6 et bitstring labels]]
* [[Recommandations opérationnelles pour l'intégration d'IPv6]]
* [[Découverte de la liste de serveurs DNS récursifs]]
* [[Propagation et mise à jour dynamique du DNS]]