Livre IPv6 - User contributions [en]

Main Page

2008-07-10T08:21:59Z

Bruno Stévant:

{{Annonce|Serveur de nouveau en ligne ! Si vous rencontrez un problème, contactez bruno.stevant AT telecom-bretagne.eu}}

=<center>'''IPv6 Théorie et Pratique'''</center>=
<center>''Gisèle Cizault''</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 nous avons décidé avec les éditions O'Reilly et le [http://www.g6.asso.fr G6]
et le support technique du [http://www.point6.net Point6]
d'en faire une version en ligne (accessible en IPv4 et IPv6). Ce serveur reprend
intégralement la quatrième édition du livre IPv6 théorie et Pratique paru en Novembre
2005 chez O'Reilly. 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

Gisèle Cizault.

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.

Talk:AG Angers

2008-07-04T10:44:30Z

Bruno Stévant:

* Un tronc commun
* Plusieurs parcours:
** Déploiement
** Mobilité

= Structure =
Approche encyclopédique : une page = un thème

Structure :
* Description
* Que disent les specs
* Implémentations (Linux, XP, etc.)
* Questions ouverte
* Sujet de recherche
* Références
* Tutorial/Case Study

'''A utiliser pour les nouveaux chapitres !'''

= Méthode de revue =
* Parcourir chaque page
* Donner une priorité de modification (cette page est elle obsolète)
* Donner une priorité d'importance du contenu (cette page est elle nécessaire pour comprendre IPv6)
'''=> Utiliser l'onglet Discussion de chaque page !'''

Talk:AG Angers

2008-07-04T10:22:42Z

Bruno Stévant:

* Un tronc commun
* Plusieurs parcours:
** Déploiement
** Mobilité

Approche encyclopédique : une page = un thème

Structure :
* Description
* Que disent les specs
* Implémentations (Linux, XP, etc.)
* Questions ouverte
* Sujet de recherche
* Références
* Tutorial/Case Study

La technique 6PE

2007-03-26T15:08:52Z

Bruno Stévant:

{{suivi| MPLS | MPLS | Exemple de mise en oeuvre de 6PE | Exemple de mise en oeuvre de 6PE}}

La technique 6PE (cf. figure Architecture 6PE) permet de connecter des îlots IPv6 entre eux au travers d'un coeur de réseau IPv4 MPLS. L'architecture utilisée est la suivante :

[[image:CS83.gif]]

* tunnels MPLS dans le coeur;
* utilisation de MP-iBGP pour annoncer les préfixes IPv6.

Ce mode, décrit dans la RFC 4798, est nommé ainsi en référence à IPv6 et aux PE des VPN MPLS (RFC 2547), mais contrairement à ces derniers, la technique 6PE ne permet pas de faire des VPN. Ainsi, les préfixes IPv6 annoncés par les routeurs CE sont placés dans la table de routage globale du routeur 6PE. La technique 6PE décrit un mode de transition vers IPv6 pour un réseau IPv4 /MPLS dans lequel :

* Comme dans un mode tunnel, les routeurs de coeur ne sont pas double pile. Ils restent en IPv4 sans aucune modification;
* Les routeurs de périphérie raccordant des clients ou des sous réseaux IPv6 sont double pile. Ils utilisent MP-iBGP pour s'échanger les préfixes de leurs clients avec eux même comme next hop ;
* Les paquets IPv6 des clients sont reçus nativement par les 6PE, encapsulés par le routeur 6PE d'entrée (ingress), décapsulés par le routeur 6PE de sortie (egress) puis envoyés aux clients sur une interface IPv6 native (ou double pile). Les tunnels sont des LSP MPLS21 (cf. figure Plan de transfert 6PE entre deux clients IPv6).

[[image:CS84.gif]]

* Aucun IGP IPv6 n'est utilisé sur les routeurs de coeur, ni sur les routeurs de périphérie. En effet, le next-hop des routes IPv6 est une route IPv6 (obligatoire en MP-BGP) mais cette adresse code en fait une adresse IPv4. Pour cela, une adresse IPv6 de type IPv4-mapped est utilisée permettant de représenter une adresse IPv4 avec une syntaxe IPv6 (le cas d'application ci-dessous en montre un exemple). Finalement, le next-hop des routes IPv6 est l'adresse IPv4 du routeur 6PE de sortie. Cette adresse IPv4 est routable grâce à l'IGP IPv4 existant.

Ce mode nécessite un maillage complet (''full mesh'') de tunnels entre les routeurs 6PE et donc un nombre de tunnels conséquent. Pour éviter la lourdeur et le coût de configuration de tout ces tunnels, le protocole MP-iBGP est utilisé : à chaque route IPv6 cliente annoncée dans MP-BGP, est associé un next-hop qui indique le point de sortie du tunnel et donc le tunnel à utiliser.

Le mode 6PE combine les avantages des modes tunnels :

* Aucun impact sur les routeurs de coeur : pas de nouveau code, pas de nouvelles fonctionnalités (commutation IPv6, [[ISIS]] MT ou IS-ISv6, MP-BGP), pas de nouvelles routes (IPv6 internes et externes), aucune dégradation des performances de commutation aussi bien pour les flux IPv4 que IPv6. Des débits IPv6 agrégés de 10G sont possibles dès maintenant. Pas de risques pris sur les routeurs et le réseau de coeur qui ne savent même qu'ils commutent de l'IPv6 (ni de l'IPv4 d'ailleurs);
* Introduction rapide : pour interconnecter deux îlots IPv6, seules deux routeurs sont à mettre à jour pour les passer en double pile (pour les interfaces natives IPv6 des clients) et configurer MP-BGP afin d'échanger les routes clientes IPv6. Or ces deux opérations sont de toutes façons indispensables, quel que soit le mode utilisé (double pile, tunnels statiques IPv4, 6PE) ;
* En cas de panne de liens ou de routeurs de coeur de réseau, les flux IPv6 peuvent utiliser l'intégralité des liens et des routeurs du réseau et donc être re-routés facilement grâce à MPLS.

Tout en supprimant de nombreux inconvénients des tunnels IPv4 statiques :

* Performance du plan de transfert: MPLS permet une encapsulation très rapide quelque soit le débit de l'interface. C'est l'interface cliente qui peut limiter les débits si les interfaces ne sont pas encore assez rapide, mais elle est à plus faible débit qu'une interface backbone. A priori, le surcoût d'encapsulation est plus faible d'où un coût de transport moins élevé pour l'opérateur et une MTU moins réduite pour le client ;
* Lourdeur de configuration des tunnels: aucun tunnel n'est à configurer manuellement. Ils sont établis automatiquement et re-routés dynamiquement en cas de panne.

Le mode 6PE a toutefois quelques inconvénients par rapport à un réseau entièrement double pile :

* Les paquets IPv6 ne sont pas transportés nativement par le réseau, or cela peut être une exigence du client (il est néanmoins possible de masquer les tunnels MPLS au client en ne recopiant pas le TTL des paquets clients dans les datagrammes MPLS).
* Certaines fonctions peuvent ne pas être disponibles une fois le trafic encapsulé dans MPLS.

{{suivi| MPLS | MPLS | Exemple de mise en oeuvre de 6PE | Exemple de mise en oeuvre de 6PE}}

La technique 6PE

2007-03-26T15:08:34Z

Bruno Stévant:

{{suivi| MPLS | MPLS | Exemple de mise en oeuvre de 6PE | Exemple de mise en oeuvre de 6PE}}

La technique 6PE (cf. figure Architecture 6PE) permet de connecter des îlots IPv6 entre eux au travers d'un coeur de réseau IPv4 MPLS. L'architecture utilisée est la suivante :

[[image:CS83.gif]]

* tunnels MPLS dans le coeur;
* utilisation de MP-iBGP pour annoncer les préfixes IPv6.

Ce mode, décrit dans la RFC4798, est nommé ainsi en référence à IPv6 et aux PE des VPN MPLS (RFC 2547), mais contrairement à ces derniers, la technique 6PE ne permet pas de faire des VPN. Ainsi, les préfixes IPv6 annoncés par les routeurs CE sont placés dans la table de routage globale du routeur 6PE. La technique 6PE décrit un mode de transition vers IPv6 pour un réseau IPv4 /MPLS dans lequel :

* Comme dans un mode tunnel, les routeurs de coeur ne sont pas double pile. Ils restent en IPv4 sans aucune modification;
* Les routeurs de périphérie raccordant des clients ou des sous réseaux IPv6 sont double pile. Ils utilisent MP-iBGP pour s'échanger les préfixes de leurs clients avec eux même comme next hop ;
* Les paquets IPv6 des clients sont reçus nativement par les 6PE, encapsulés par le routeur 6PE d'entrée (ingress), décapsulés par le routeur 6PE de sortie (egress) puis envoyés aux clients sur une interface IPv6 native (ou double pile). Les tunnels sont des LSP MPLS21 (cf. figure Plan de transfert 6PE entre deux clients IPv6).

[[image:CS84.gif]]

* Aucun IGP IPv6 n'est utilisé sur les routeurs de coeur, ni sur les routeurs de périphérie. En effet, le next-hop des routes IPv6 est une route IPv6 (obligatoire en MP-BGP) mais cette adresse code en fait une adresse IPv4. Pour cela, une adresse IPv6 de type IPv4-mapped est utilisée permettant de représenter une adresse IPv4 avec une syntaxe IPv6 (le cas d'application ci-dessous en montre un exemple). Finalement, le next-hop des routes IPv6 est l'adresse IPv4 du routeur 6PE de sortie. Cette adresse IPv4 est routable grâce à l'IGP IPv4 existant.

Ce mode nécessite un maillage complet (''full mesh'') de tunnels entre les routeurs 6PE et donc un nombre de tunnels conséquent. Pour éviter la lourdeur et le coût de configuration de tout ces tunnels, le protocole MP-iBGP est utilisé : à chaque route IPv6 cliente annoncée dans MP-BGP, est associé un next-hop qui indique le point de sortie du tunnel et donc le tunnel à utiliser.

Le mode 6PE combine les avantages des modes tunnels :

* Aucun impact sur les routeurs de coeur : pas de nouveau code, pas de nouvelles fonctionnalités (commutation IPv6, [[ISIS]] MT ou IS-ISv6, MP-BGP), pas de nouvelles routes (IPv6 internes et externes), aucune dégradation des performances de commutation aussi bien pour les flux IPv4 que IPv6. Des débits IPv6 agrégés de 10G sont possibles dès maintenant. Pas de risques pris sur les routeurs et le réseau de coeur qui ne savent même qu'ils commutent de l'IPv6 (ni de l'IPv4 d'ailleurs);
* Introduction rapide : pour interconnecter deux îlots IPv6, seules deux routeurs sont à mettre à jour pour les passer en double pile (pour les interfaces natives IPv6 des clients) et configurer MP-BGP afin d'échanger les routes clientes IPv6. Or ces deux opérations sont de toutes façons indispensables, quel que soit le mode utilisé (double pile, tunnels statiques IPv4, 6PE) ;
* En cas de panne de liens ou de routeurs de coeur de réseau, les flux IPv6 peuvent utiliser l'intégralité des liens et des routeurs du réseau et donc être re-routés facilement grâce à MPLS.

Tout en supprimant de nombreux inconvénients des tunnels IPv4 statiques :

* Performance du plan de transfert: MPLS permet une encapsulation très rapide quelque soit le débit de l'interface. C'est l'interface cliente qui peut limiter les débits si les interfaces ne sont pas encore assez rapide, mais elle est à plus faible débit qu'une interface backbone. A priori, le surcoût d'encapsulation est plus faible d'où un coût de transport moins élevé pour l'opérateur et une MTU moins réduite pour le client ;
* Lourdeur de configuration des tunnels: aucun tunnel n'est à configurer manuellement. Ils sont établis automatiquement et re-routés dynamiquement en cas de panne.

Le mode 6PE a toutefois quelques inconvénients par rapport à un réseau entièrement double pile :

* Les paquets IPv6 ne sont pas transportés nativement par le réseau, or cela peut être une exigence du client (il est néanmoins possible de masquer les tunnels MPLS au client en ne recopiant pas le TTL des paquets clients dans les datagrammes MPLS).
* Certaines fonctions peuvent ne pas être disponibles une fois le trafic encapsulé dans MPLS.

{{suivi| MPLS | MPLS | Exemple de mise en oeuvre de 6PE | Exemple de mise en oeuvre de 6PE}}

Talk:L'interface de programmation "socket" IPv6

2007-03-22T16:48:26Z

Bruno Stévant:

la structure <tt>sockaddr_in6</tt> contient un champ sin6_len pour être compatible avec <tt>sockaddr_storage</tt>. -- BS

Talk:Configuration avec état :DHCPv6

2007-02-22T09:46:29Z

Bruno Stévant:

Ca manque cruellement de Délégation de préfixe. Mais cela ne devrait pas plutôt être traité dans [[Configuration des routeurs]] ? -- [[Utilisateur:Bruno_Stévant|BS]]

TODO: Ajouter la figure "Structure des lessages de relais" (p82)

== DSTM ==

L'option DSTM est introuvable dans le RFC DHCPv6. Peut etre ce chapitre meriterait une mise a jour ;)
Sinon, d'accord avec BS en ce qui concerne le PD.
BD

== Options DHCPv6 ==

Bonjour, j'ai essayé de remettre a jour les options DHCPv6, je mets ca ici en attente de commentaire avant intégration.
Merci
-- BD

J'ai ajouté les attributs RADIUS définis dans [http://bgp.potaroo.net/ietf/draft-ietf-dhc-v6-relay-radius-01.txt]. Ces options sont valables dans les messages Relay uniquement : peut être devrait-on mieux différencier la sémantique des options en fonction des messages ? -- BS

-> Je suis d'accord... Le systeme de changement de couleur est assez pénible donc du coup j'ai pas eu le courage de reordonner tout ca. On fait quoi ? Server - Client - Relai ?

Il faudrait déjà présenter fonctionnement avec relais (=> nouvelle figure ?) et indiquer pour chaque option dans quelle contexte elle peut être utiliser (=> une collone du tableau en plus ?). On détaillera après la sémantique quand il y en a besoin.

-> Pfiou, ca fait du boulot ca :) Pour al colone en plus je vois pas trop quoi y mettre en fait ?
Pour el Schéma je veux bien essayer de faire ca... mais il y a deja un paragraphe qui l explique il me semble non ?
Du coup, pour faire plaisir a Laurent, on rajoute les options définies dans [http://www.ipv6.rennes.enst-bretagne.fr/dstm/draft-ietf-dhc-dhcpv6-opt-dstm-01.txt] ?

''Petite légende des abréviations utilisées a insérer quelque part''
*RC : Requete Client
*RS : Réponse Serveur
*RCR : Requete Client Relayée
*RSR : Requete Serveur Relayée
*OO : Option d'option.

{|
|+'''Options de DHCPv6'''
! Désignation || Définition || Utilisation
|-style="background:silver"
|Association d'Identification pour Adresses Temporaires (IA_TA)|| Liste des adresses IPv6 d'une interface du client.|| RC et RS.
|-
|Association d'Identification pour Adresses Permanentes (IA_NA) || Liste des adresses IPv6 permanentes d'une interface du client. || RC et RS.
|-style="background:silver"
|Adresse de l'IA (IA_ADDR) || Option encapsulée dans une option IA_TA ou IA_NA pour spécifier une des adresses de l'association.|| IA_TA et IA_NA.
|-
|Requêtes d'options (ORO) ||Liste des informations de configuration demandées par le client.|| RC et RS.
|-style="background:silver"
|Message relayé || Pour l'encapsulation du message DHCP du client ou du serveur par le relais.|| RCR et RSR.
|-
|Authentification || Pour authentification de la source du message DHCP et de la validation de son intégrité.|| RC, RS, RCR et RSR.
|-style="background:silver"
|Serveur Unicast || Permet d'autoriser le client a utiliser l'adresse unicast du serveur (spécifiée dans l'option) pour le contacter directement. Ces messages ne peuvent passer par un relais DHCP.|| RS.
|-
|Identifiant du Client || Identifiant permanent du client (DUID).|| RC.
|-style="background:silver"
|Identifiant du Serveur || Identifiant permanent du serveur (DUID).|| RS.
|-
|Préférence || Moyen donné au client de choisir le serveur DHCP. Le serveur sélectionné aura en charge de fournir les paramètres de configuration à ce client.|| RS.
|-style="background:silver"
|Temps écoulé || Cette option doit être incluse par le client pour indiquer depuis combien de temps il essaye de finaliser l'échange. Permet le déclenchement d'un serveur secondaire si le temps écoulé dépasse une certaine valeur.|| RC.
|-
|Code d'état || Permet d'ajouter des codes d'état dans les options DHCP. Si cette option est absente, le code par défaut est "Succès".|| RC, RS, RCR, RSR et OO.
|-style="background:silver"
|Validation Rapide (Rapid Commit) || Permet au client d'indiquer qu'il peut utiliser la procédure de validation rapide (échange simplifié de messages sans acquittement).|| RC et RS.
|-
|Classe d'utilisateur || Permet de spécifier la/les classe(s) d'un utilisateur afin de récupérer des informations génériques a ce groupe. || RC.
|-style="background:silver"
|Classe de matériel || Permet de spécifier le matériel/OS du client afin d'obtenir des informations spécifiques.|| RC.
|-
|Identifiant d'Interface || Permet a un relais de connaître l'interface sur laquelle le client a envoyé la requête.|| RCR et RSR.
|-style="background:silver"
|Information constructeur || Permet de spécifier le constructeur du matériel afin de réaliser des configurations spécifiques.|| RC et RS.
|-
|Message de reconfiguration || Utilisé par le serveur dans un message de reconfiguration pour indiquer au client s'il doit répondre par une requête "Renouvellement DHCP" ou "Requete DHCP".|| RS.
|-style="background:silver"
|Acquittement de reconfiguration || Permet au client d'indiquer au serveur qu'il peut accepter les messages de reconfiguration et au serveur de demander au client d'accepter ces messages ou non.|| RS.
|-
|Attributs RADIUS (RRAO) [http://bgp.potaroo.net/ietf/draft-ietf-dhc-v6-relay-radius-01.txt]|| Utilisé par le relais pour fournir au serveur des informations supplémentaires sur le client provenant d'une base RADIUS : (nom de l'utilisateur, préfixes ou pool d'allocation de préfixes IPv6).|| RCR.
|}

Configuration automatique

2007-02-21T22:40:12Z

Bruno Stévant:

{{suivi|Exemples de découverte de voisins|Exemples de découverte de voisins|Exemples de configuration sans état|Exemples de configuration sans état}}
Traditionnellement, la configuration d'une interface réseau d'une machine demande une configuration manuelle. C'est un travail souvent long et fastidieux. Avec IPv6, cette configuration est automatisée, introduisant par là-même des caractéristiques de fonctionnement immédiat (''plug and play'') à l'interface réseau. La configuration automatique signifie qu'une machine obtient toutes les informations nécessaires à sa connexion à un réseau local IP sans aucune intervention humaine. Dans le cas idéal, un utilisateur quelconque déballe son nouvel ordinateur, le connecte au réseau local et le voit fonctionner sans devoir y introduire des informations de "spécialiste". Nous avons vu [[Exemples de découverte de voisins#defaut|comment les routes étaient installées]] dans la table de routage des machines. Nous allons maintenant étudier l'autre aspect de l'autoconfiguration de IPv6 qui est l'autoconfiguration d'adresses. Celle-ci a pour objectif :

* l'acquisition d'une adresse quand une machine est attachée à un réseau pour la première fois ;
* l'obtention de la nouvelle adresse suite à la renumérotation des machines du site après un changement d'opérateur. L'opération de renumérotation revient concrètement à changer la partie haute de l'adresse. L'autoconfiguration d'adresses va servir de vecteur dans l'attribution du nouveau préfixe.

Le processus d'autoconfiguration d'adresse d'IPv6 comprend la création d'une adresse lien-local, la vérification de son unicité et la détermination d'adresses unicast globales. IPv6 spécifie deux méthodes d'autoconfiguration pour l'adresse unicast globale :

* l'autoconfiguration sans état (''stateless autoconfiguration'', RFC 2462) ; elle est utilisée quand la gestion administrative des adresses attribuées n'est pas nécessaire au sein d'un site. Ces mécanismes sont décrits dans la suite de ce chapitre.
* l'autoconfiguration avec état (''stateful autoconfiguration'') ; elle est retenue lorsqu'un site demande un contrôle strict de l'attribution des adresses (cf. [[Configuration avec état :DHCPv6|DHCPv6]]).

Le rôle du routeur est important dans l'autoconfiguration. Il dicte à la machine, par des bits (cf. [[Découverte de voisins#RA|Annonce du routeur]]) de l'en-tête du message d'annonce de routeurs, la méthode à retenir et fournit éventuellement les informations nécessaires à sa configuration. Le bit <tt>M</tt> (''Managed address configuration'') mis à 1 indique que l'équipement ne doit pas construire lui-même l'adresse à partir de son identifiant d'interface et des préfixes reçus, mais doit explicitement demander son adresse auprès d'une application d'un serveur d'adresses. Le bit <tt>O</tt> (''Other stateful configuration'') indique que l'équipement doit interroger le serveur de configuration pour obtenir des paramètres autre que l'adresse. L'algorithme de la procédure d'autoconfiguration d'adresse se décompose de la manière suivante :

* La toute première étape consiste à créer l'adresse lien-local.
* Une fois l'unicité de cette adresse vérifiée, la machine est en mesure de communiquer avec les autres machines du lien.
* La machine doit chercher à acquérir un message d'annonce du routeur pour déterminer la méthode d'obtention de l'adresse unicast globale.
* S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message d'annonce de routeurs, à savoir :
** l'autoconfiguration sans état,
** l'autoconfiguration avec état.
* En l'absence de routeur sur le lien, la machine doit essayer d'acquérir l'adresse unicast globale par la méthode d'autoconfiguration avec état. Si la tentative échoue, c'est terminé. Les communications se feront uniquement sur le lien avec l'adresse lien-local. La machine n'a pas une adresse avec une portée qui l'autorise à communiquer avec des machines autres que celles du lien.

==Création de l'adresse lien-local==

À l'initialisation de son interface, la machine construit un identifiant pour l'interface qui doit être unique au lien. Cet identifiant utilise l'adresse [[Identifiant_d'interface#EUI-64|EUI-64]]. Le principe de base de la création d'adresse IPv6 est de marier un préfixe avec l'identifiant. L'adresse lien-local est créée en prenant le préfixe lien-local (<tt>FE80::/64</tt>) qui est fixé. L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire car la machine doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée. Si la machine détermine l'adresse lien-local n'est pas unique, l'autoconfiguration s'arrête et une intervention manuelle est nécessaire.

Une fois que l'assurance sur l'unicité de l'adresse lien-local est obtenue, l'adresse provisoire devient une adresse valide pour l'interface. La première phase de l'autoconfiguration est achevée.

==<div id="DAD"> Détection d'adresse dupliquée </div>==

Pour vérifier l'unicité des adresses lien-local ou unicast, les machines doivent exécuter un algorithme de Détection d'Adresse Dupliquée (DAD) avant de les utiliser. L'algorithme utilise les messages ICMPv6 [[Découverte de voisins#NS|sollicitation d'un voisin]] et [[Découverte de voisins#NA|annonce d'un voisin]]. Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'autoconfiguration s'arrête et une intervention humaine devient obligatoire. Une adresse est qualifiée de "provisoire" pendant l'exécution de l'algorithme DAD et ce jusqu'à la confirmation de son unicité. Une adresse provisoire est assignée à une interface uniquement pour recevoir les messages de sollicitation et d'annonce d'un voisin. Les autres messages reçus sont ignorés. L'algorithme DAD consiste à envoyer un message sollicitation d'un voisin avec dans le champ adresse de la cible l'adresse provisoire. Afin de distinguer l'algorithme DAD de celui de découverte des voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de source l'adresse indéterminée. Trois cas se présentent :

* Un message annonce d'un voisin est reçu : l'adresse provisoire est utilisée comme adresse valide par une autre machine. L'adresse provisoire n'est pas unique et ne peut être retenue.
* Un message sollicitation d'un voisin est reçu dans le cadre d'une procédure DAD; l'adresse provisoire est également une adresse provisoire pour une autre machine. L'adresse provisoire ne peut être utilisée par aucune des machines.
* Rien n'est reçu au bout d'une seconde (valeur par défaut) : l'adresse provisoire est unique, elle passe de l'état de provisoire à celle de valide et elle est assignée à l'interface.

A noter que cet algorithme n'offre pas une fiabilité absolue, notamment lorsque le lien est coupé.

== Autoconfiguration sans état ==

L'autoconfiguration sans état (RFC 2462) ne demande aucune configuration manuelle des machines, une configuration minimum pour les routeurs et aucun serveur supplémentaire. Elle se sert du protocole ICMPv6 et peut fonctionner sans la présence de routeurs. Elle nécessite cependant un sous-réseau à diffusion. Cette méthode ne s'applique que pour les machines et ne peut être retenue pour la configuration des routeurs. Le principe de base de l'autoconfiguration sans état est qu'une machine génère son adresse IPv6 à partir d'informations locales et d'informations fournies par un routeur. Le routeur fournit à la machine les informations sur le sous-réseau associé au lien, il donne le préfixe.

Comme pour la création de l'adresse lien-local, l'adresse unicast globale est obtenue en concaténant le préfixe avec l'identifiant de l'interface. Le préfixe provient du message d'annonce de routeurs et plus précisément de l'option «information sur le préfixe». Bien qu'il faille vérifier l'unicité de toutes les adresses unicast, dans le cas d'une adresse unicast obtenue par autoconfiguration sans état cela n'est pas obligatoire. En effet, l'unicité de l'identifiant de l'interface a déjà été contrôlé dans l'étape de création de l'adresse lien-local. L'identifiant étant le même, il n'y a plus aucune ambiguïté sur son unicité. L'adresse unicast globale constituée est aussi unique que celle lien-local.

La renumérotation des machines d'un lien s'effectue au moyen des routeurs qui passent les adresses utilisées dans un état déprécié et annoncent en même temps le nouveau préfixe. Les machines pourront recréer une adresse préférée.
{{suivi|Exemples de découverte de voisins|Exemples de découverte de voisins|Exemples de configuration sans état|Exemples de configuration sans état}}

Talk:Configuration automatique

2007-02-21T22:38:31Z

Bruno Stévant:

L'autoconfiguration sans état (RFC 2462) ne demande aucune configuration manuelle des machines, une configuration minimum pour les routeurs et aucun serveur supplémentaire. Elle se sert du protocole ICMPv6 et peut fonctionner sans la présence de routeurs.

Question: la dernière phrase est-elle vraie ?

Configuration automatique

2007-02-21T22:23:47Z

Bruno Stévant:

{{suivi|Exemples de découverte de voisins|Exemples de découverte de voisins|Exemples de configuration sans état|Exemples de configuration sans état}}
Traditionnellement, la configuration d'une interface réseau d'une machine demande une configuration manuelle. C'est un travail souvent long et fastidieux. Avec IPv6, cette configuration est automatisée, introduisant par là-même des caractéristiques de fonctionnement immédiat (''plug and play'') à l'interface réseau. La configuration automatique signifie qu'une machine obtient toutes les informations nécessaires à sa connexion à un réseau local IP sans aucune intervention humaine. Dans le cas idéal, un utilisateur quelconque déballe son nouvel ordinateur, le connecte au réseau local et le voit fonctionner sans devoir y introduire des informations de "spécialiste". Nous avons vu [[Exemples de découverte de voisins#defaut|comment les routes étaient installées]] dans la table de routage des machines. Nous allons maintenant étudier l'autre aspect de l'autoconfiguration de IPv6 qui est l'autoconfiguration d'adresses. Celle-ci a pour objectif :

* l'acquisition d'une adresse quand une machine est attachée à un réseau pour la première fois ;
* l'obtention de la nouvelle adresse suite à la renumérotation des machines du site après un changement d'opérateur. L'opération de renumérotation revient concrètement à changer la partie haute de l'adresse. L'autoconfiguration d'adresses va servir de vecteur dans l'attribution du nouveau préfixe.

Le processus d'autoconfiguration d'adresse d'IPv6 comprend la création d'une adresse lien-local, la vérification de son unicité, la détermination de adresses unicasts globales. IPv6 spécifie deux méthodes d'autoconfiguration pour l'adresse unicast globale :

* l'autoconfiguration sans état (stateless autoconfiguration, RFC 2462) ; elle est utilisée quand la gestion administrative des adresses attribuées n'est pas nécessaire au sein d'un site. Ces mécanismes sont décrit dans la suite de ce chapitre.
* l'autoconfiguration avec état (stateful autoconfiguration) ; elle est retenue lorsqu'un site demande un contrôle strict de l'attribution des adresses. Ce mécanisme est décrit Autoconfiguration avec état [[Configuration avec état :DHCPv6|DHCPv6]].

Le rôle du routeur est important dans l'autoconfiguration. Il dicte à la machine, par des bits (cf. [[Découverte de voisins#RA|Annonce du routeur]]) de l'en-tête du message d'annonce de routeurs, la méthode à retenir et fournit éventuellement les informations nécessaires à sa configuration. Le bit <tt>M</tt> (''Managed address configuration'') mis à 1 indique que l'équipement ne doit pas construire lui-même l'adresse à partir de son identifiant d'interface et des préfixes reçus, mais doit explicitement demander son adresse auprès d'une application d'un serveur d'adresse. Le bit <tt>O</tt> (''Other stateful configuration'') indique que l'équipement doit interroger le serveur de configuration pour obtenir des paramètres autre que l'adresse. L'algorithme de la procédure d'autoconfiguration d'adresse se décompose de la manière suivante :

* La toute première étape consiste à créer l'adresse lien-local.
* Une fois l'unicité de cette adresse vérifiée, la machine est en mesure de communiquer avec les autres machines du lien.
* La machine doit chercher à acquérir un message d'annonce du routeur pour déterminer la méthode d'obtention de l'adresse unicast globale.
* S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message d'annonce de routeurs, à savoir :
** l'autoconfiguration sans état,
** l'autoconfiguration avec état.
* En l'absence de routeur sur le lien, la machine doit essayer d'acquérir l'adresse unicast globale par la méthode d'autoconfiguration avec état. Si la tentative échoue, c'est terminé. Les communications se feront uniquement sur le lien avec l'adresse lien-local. La machine n'a pas une adresse avec une portée qui l'autorise à communiquer avec des machines autres que celles du lien.

==<div id="DAD"> Détection d'adresse dupliquée </div>==

Pour vérifier l'unicité des adresses unicast, les machines doivent exécuter un algorithme de Détection d'Adresse Dupliquée (DAD) avant de les utiliser. L'algorithme utilise les messages ICMPv6 [[Découverte de voisins#NS|sollicitation d'un voisin]] et [[Découverte de voisins#NA|annonce d'un voisin]]. Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'autoconfiguration s'arrête et une intervention humaine devient obligatoire. Une adresse est qualifiée de "provisoire" pendant l'exécution de l'algorithme DAD et ce jusqu'à la confirmation de son unicité. Une adresse provisoire est assignée à une interface uniquement pour recevoir les messages de sollicitation et d'annonce d'un voisin. Les autres messages reçus sont ignorés. L'algorithme DAD consiste à envoyer un message sollicitation d'un voisin avec dans le champ adresse de la cible l'adresse provisoire. Afin de distinguer, l'algorithme DAD de celui de découverte des voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de source l'adresse indéterminée. Trois cas se présentent :

* Un message annonce d'un voisin est reçu : l'adresse provisoire est utilisée comme adresse valide par une autre machine. L'adresse provisoire n'est pas unique et ne peut être retenue.
* Un message sollicitation d'un voisin est reçu dans le cadre d'une procédure DAD; l'adresse provisoire est également une adresse provisoire pour une autre machine. L'adresse provisoire ne peut être utilisée par aucune des machines.
* Rien n'est reçu au bout d'une seconde (valeur par défaut) : l'adresse provisoire est unique, elle passe de l'état de provisoire à celle de valide et elle est assignée à l'interface.

A noter que cet algorithme n'offre pas une fiabilité absolue, notamment lorsque le lien est coupé.

==Création de l'adresse lien-local==

À l'initialisation de son interface, la machine construit un identifiant pour l'interface qui doit être unique au lien. Cet identifiant utilise l'adresse [[Identifiant_d'interface#EUI-64|EUI-64]]. Le principe de base de la création d'adresse IPv6 est de marier un préfixe avec l'identifiant. L'adresse lien-local est créée en prenant le préfixe lien-local (<tt>FE80::/64</tt>) qui est fixé. L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire car la machine doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée. Si la machine détermine l'adresse lien-local n'est pas unique, l'autoconfiguration s'arrête et une intervention manuelle est nécessaire.

Une fois que l'assurance sur l'unicité de l'adresse lien-local est obtenue, l'adresse provisoire devient une adresse valide pour l'interface. La première phase de l'autoconfiguration est achevée.

== Autoconfiguration sans état ==

L'autoconfiguration sans état (RFC 2462) ne demande aucune configuration manuelle des machines, une configuration minimum pour les routeurs et aucun serveur supplémentaire. Elle se sert du protocole ICMPv6 et peut fonctionner sans la présence de routeurs. Elle nécessite cependant un sous-réseau à diffusion. Cette méthode ne s'applique que pour les machines et ne peut être retenue pour la configuration des routeurs. Le principe de base de l'autoconfiguration sans état est qu'une machine génère son adresse IPv6 à partir d'informations locales et d'informations fournies par un routeur. Le routeur fournit à la machine les informations sur le sous-réseau associé au lien, il donne le préfixe.

Comme pour la création de l'adresse lien-local, l'adresse unicast globale est obtenue en concaténant le préfixe avec l'identifiant de l'interface. Le préfixe provient du message d'annonce de routeurs et plus précisément de l'option «information sur le préfixe». Bien qu'il faille vérifier l'unicité de toutes les adresses unicast, dans le cas d'une adresse unicast obtenue par autoconfiguration sans état cela n'est pas obligatoire. En effet, l'unicité de l'identifiant de l'interface a déjà été contrôlé dans l'étape de création de l'adresse lien-local. L'identifiant étant le même, il n'y a plus aucune ambiguïté sur son unicité. L'adresse unicast globale constituée est aussi unique que celle lien-local.

La re-numérotation des machines d'un lien s'effectue au moyen des routeurs qui passent les adresses utilisées dans un état déprécié et annoncent en même temps le nouveau préfixe. Les machines pourront recréer une adresse préférée.
{{suivi|Exemples de découverte de voisins|Exemples de découverte de voisins|Exemples de configuration sans état|Exemples de configuration sans état}}

Talk:Exemples de découverte de voisins

2007-02-21T11:28:37Z

Bruno Stévant:

TODO: Figure pour "Indication de redirection externe" à faire

Exemples de découverte de voisins

2007-02-21T11:21:11Z

Bruno Stévant: /* <div id="defaut">Configuration de la route par défaut</div> */

{{suivi|Découverte de voisins|Découverte de voisins|Configuration automatique|Configuration automatique}}
==Ping et résolution d'adresses==

Les paquets suivants ont été obtenus lors d'un ping entre deux stations IPv6 situées sur le même réseau physique de type Ethernet.

uma# '''ping6 ganesha'''
trying to get source for ganesha
source should be 3ffe:302:12:3:a00:20ff:fe0a:aa6d
PING ganesha (3ffe:302:12:3::3): 56 data bytes
64 bytes from 3ffe:302:12:3::3: icmp6_seq=0 ttl=255 time=5.121 ms

Avant de pouvoir émettre un paquet ICMPv6 de demande d'écho, l'émetteur a besoin de connaître l'adresse physique de l'équipement destinataire. Il utilise le protocole de découverte des voisins et émet une trame de sollicitation d'un voisin.

Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:0:0:3 Type : 0x86dd
IPv6
Version : 6 Classe : 0xf0 Label : 000000
Longueur : 32 octets (0x0020) Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 255 (0xff)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : ff02::1:ff00:3 (multicast sollicité associé à 3ffe:302:12:3::3)
ICMPv6
Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x4d7f
Cible : 3ffe:302:12:3::3 (ganesha)
Option :
Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d

0000: ''6<font color="blue">f 0</font>0 00 00 <font color="blue">00 20</font> 3a <font color="blue">ff</font> 3f fe 03 02 00 12 00 03''
0010: ''0a 00 20 ff fe 0a aa 6d <font color="blue">ff 02 00 00 00 00 00 00</font>''
0020: ''<font color="blue">00 00 00 01 ff 00 00 03</font>|87 <font color="blue">00</font> 4d 7f <font color="blue">00 00 00 00</font>''
0030: ''3f fe 03 02 00 12 00 03 00 00 00 00 00 00 00 03|''
0040: ''01 <font color="blue">01</font> 08 00 20 0a aa 6d''

Dans l'en-tête IPv6, l'adresse de la source est l'adresse globale de l'interface d'émission. On aurait pu penser que l'émetteur utilisait l'adresse locale au lien comme adresse de la source. L'utilisation de l'adresse source globale, comme on le verra par la suite, permet au destinataire de remplir directement sa table de correspondance entre adresse IPv6 et adresse physique, puisque ce dernier trouvera dans la suite du datagramme l'adresse physique de l'émetteur.

L'adresse de destination est l'adresse de [[Réseaux à diffusion#sol|multicast sollicité]] associée à l'adresse recherchée et l'adresse Ethernet de destination est l'adresse associée (cf. [[Supports de transmission]] RFC 2464).

L'en-tête ICMPv6 contient dans le champ cible l'adresse IPv6 de la machine dont l'adresse physique est recherchée. On peut remarquer que les trois derniers octets correspondent au groupe de multicast de l'en-tête IPv6.

Le champ option contient l'adresse physique de l'émetteur de la requête.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd
IPv6
Version : 6 Classe : 0xf0 Label : 000000
Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 255 (0xff)
Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)
Desti. : 3ffe:302:12:3:0a00:20ff:fe0a:aa6d (uma)
ICMPv6
Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0xd7fb
Bits (0x7) R = 1, S = 1, O = 1
Cible : 3ffe:302:12:3::3 (ganesha)
Option :
Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34

La machine <tt>ganesha</tt>, qui écoute sur tous les groupes [[Réseaux à diffusion#sol|multicast sollicité]] associés à ses adresses, reçoit le message de sollicitation de voisin, reconnaît dans la cible une de ses adresses IPv6, et répond. L'adresse source utilisée est locale au lien. Le bit <tt>R</tt> indique que l'équipement qui répond a une fonction de routeur. Le bit <tt>S</tt> indique que ce message est une réponse à une demande explicite (le message précédent). Le bit <tt>O</tt> indique que cette réponse doit remplacer toute valeur connue précédemment. Le champ cible rappelle l'adresse IPv6. Le champ option donne l'adresse physique recherchée.

Ethernet Src : 8:0:20:a:aa:6d Dst : 1a:0:20:c:7a:34 Type : 0x86dd
IPv6
Version : 6 Classe : 0x00 Label : 000000
Longueur : 64 octets (0x0040) Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 255 (0xff)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : 3ffe:302:12:3::3 (ganesha)
ICMPv6
Type : 128 (0x80, Demande d'écho) Code : 0 Checksum : 0x0f20
Identificateur : 0x00c0 Numéro de séquence : 0x0000
Données : Date : 0x3468c4c7.000631c7 Remplissage ...

L'émetteur envoie un message ICMPv6 [[ICMPv6#echo|Demande d'écho]].

Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd
IPv6
Version : 6 Classe : 0x00 Label : 000000
Longueur : 64 octets (0x0040) Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 255 (0xff)
Source : 3ffe:302:12:3::3 (ganesha)
Desti. : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
ICMPv6
Type : 129 (0x81, Réponse d'écho) Code : 0 Checksum : 0x0e20
Identificateur : 0x00c0 Numéro de séquence : 0x0000
Données : Celles de la demande

Le destinataire acquitte en retournant un message ICMPv6 [[ICMPv6#echo|Réponse d'écho]]. Il n'est pas nécessaire de relancer une phase de résolution d'adresse puisque la précédente a permis de remplir le cache.

Les échanges ICMP [[ICMPv6#echo|Demande d'écho]] et [[ICMPv6#echo|Réponse d'écho]] continuent ensuite toutes les secondes. Si les échanges continuent assez longtemps, les deux machines vérifieront périodiquement que le correspondant est toujours correct (il a pu tomber en panne ou être remplacé avec changement d'adresse Ethernet) en utilisant le protocole [[Découverte de voisins#NUD|NUD]]. Aussi de temps en temps, chaque machine va émettre une trame [[Découverte de voisins#NS|sollicitation d'un voisin]]. Une réponse ([[Découverte de voisins#NA|annonce de voisin]] avec le bit <tt>S</tt>) montre que le correspondant est toujours valide.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd
IPv6
Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)
Desti. : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
ICMPv6
Type : 135 (0x87, Sollicitation de voisin) Code : 0
Cible : 3f fe 03 02 00 12 00 03 0a 00 20 ff fe 0a aa 6d
Option : aucune

On remarque que le message de sollicitation est directement adressé au destinataire, avec l'adresse qui est enregistrée dans les tables de correspondance. Si une réponse n'arrive pas, la machine émettrice effacera l'entrée de son cache «Résolution de voisin». Tout trafic ultérieur reprendra l'enquête de résolution au début, avec diffusion vers l'adresse [[Réseaux à diffusion#sol|multicast sollicité]]-- au cas où l'adresse Ethernet aurait changée.

== <div id="defaut">Configuration de la route par défaut</div> ==

[[image:Fig5-10.png|thumb|right|400px|Figure 5-10 ''Annonces du routeur'']]

En IPv6 seuls les routeurs utilisent des protocoles de routage pour définir leurs tables de routage. Le routage des autres machines repose sur la notion de route par défaut. Comme avec IPv4, l'envoi de messages de redirection est utilisé pour installer de meilleures routes. Périodiquement les routeurs envoient des [[Découverte de voisins#RA|Annonces du routeur]] qui permettent aux machines sur le câble de choisir un routeur par défaut, et aussi de calculer leur adresse (dans le mode d'autoconfiguration sans état stateless).

Un même câble Ethernet relie 3 machines (cf. figure Annonces de routeurs) :

* deux routeurs <tt>ganesha</tt> et <tt>tuna</tt>,
* et une autre machine <tt>uma</tt>.

Les routeurs émettent périodiquement sur le réseau des messages d'annonce.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 33:33:0:0:0:1 Type : 0x86dd
IPv6
Version : 6 Classe : 0xf Label : 000000
Longueur : 56 octets (0x0038) Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 255 (0xff)
Source : fe80::1800:200c:7a34 (ganesha, lien-local)
Desti. : ff02::1 (multicast, tous les n??uds du lien)
ICMPv6
Type : 134 (0x86, Annonce de routeur) Code : 0 Checksum : 0x773c
Nombre de sauts : 0 (non précisé) Gestion d'adresse : 0 (Pas de DHCP)
Validité : 6000 secondes (0x1770) Timers : 0, 0 (non précisés)
Options :
Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34
Type : 3 (Information sur le préfixe) Lg : 32 octets (0x04)
Drapeaux : L=1, A=1 Durée de validité : -1, -1 (infinie)
Préfixe : 3ffe:302:12:3::/64

0000: 6<font color="blue">f 0</font>0 00 00 <font color="blue">00 38</font> 3a <font color="blue">ff</font> fe 80 00 00 00 00 00 00
0010: 18 00 20 ff fe 0c 7a 34 <font color="blue">ff 02 00 00 00 00 00 00</font>
0020: <font color="blue">00 00 00 00 00 00 00 01</font>|86 <font color="blue">00</font> 77 3c <font color="blue">00</font> 00 <font color="blue">17 70</font>
0030: 00 00 00 00 00 00 00 00|<font color="blue">01</font> 01 <font color="blue">1a 00 20 0c 7a 34</font>|
0040: 03 <font color="blue">04</font> 40 c0 ff ff ff ff ff ff ff ff 00 00 00 00
0050: <font color="blue">3f fe 03 02 00 12 00 03 00 00 00 00 00 00 00 00</font>

Ce message est envoyé par le routeur <tt>ganesha</tt> (l'adresse source est l'adresse locale, commençant par <tt>fe80</tt>), à destination de tous les noeuds sur le câble Ethernet (adresse de destination IPv6 «Tous les noeuds sur le lien» <tt>ff02::1</tt> et l'adresse de destination physique est l'adresse MAC de multicast associée). Les informations donnent la durée de vie de cette annonce, des paramètres de configuration pour les noeuds, dont le type de construction d'adresse : mode d'autoconfiguration ''stateless'' en créant une adresse permanente à partir du préfixe <tt>3ffe:302:12:3::/64</tt>.

La table de routage d'<tt>uma</tt> après réception de ce message contient :

uma# '''netstat -nrf inet6'''
Routing tables IPv6:
Destination Gateway Flags Refs Use Mtu Interf
default fe80::1800:20ff:fe0c:7a34 UGS 0 17 1500 le0
fe80::1800:20ff:fe0c:7a34 1a:0:20:c:7a:34 U HDL 1 2 1500 le0
.....

La ligne avec le drapeau <tt>L</tt> correspond à une machine directement accessible, le champ ''Gateway'' contient l'adresse IEEE 802. Il s'agit des informations contenues dans la table de correspondance construite par le protocole de découverte des voisins.

Le routeur <tt>tuna</tt> avait lui aussi émis des annonces de routeur. On pourrait donc aussi enregistrer une route par défaut via <tt>tuna</tt> ; mais le système ne conserve qu'une route par défaut, et la route possible par <tt>tuna</tt> est ignorée. De même, il n'y a pas de ligne de correspondance adresse IPv6-adresse Ethernet pour <tt>tuna</tt> car cette adresse n'a pas été utilisée comme destination.

==<div id="indredir">Indication de redirection</div>==

[[image:Fig5-11.png|thumb|right|400px|Figure 5-11 ''Routage par défaut non optimal'']]

La configuration donnée figure Routage par défaut non optimal après la configuration des routes par défaut conduit aux tables de routage suivantes : la route par défaut d'<tt>uma</tt> pointe sur <tt>ganesha</tt>, et la route vers la machine externe <tt>3ffe:200:1:3::1</tt> sur <tt>ganesha</tt> pointe sur <tt>tuna</tt>.

La machine <tt>uma</tt> envoie un ping à la machine externe <tt>3ffe:200:1:3::1</tt> en utilisant la route par défaut, non optimale.

uma# '''ping6 3ffe:200:1:3::1'''
trying to get source for 3ffe:200:1:3::1
source should be 3ffe:302:12:3:a00:20ff:fe0a:aa6d
PING 3ffe:200:1:3::1: 56 data bytes
64 bytes from 3ffe:200:1:3::1: icmp6_seq=0 ttl=253 time=79.689 ms
.....

En observant le réseau, on trouve le trafic suivant.

Ethernet Src : 8:0:20:a:aa:6d Dst : 1a:0:20:c:7a:34 Type : 86dd
IPv6
Version : 6 Classe : 0x00 Label : 000000
Longueur : 64 octets (0x0040) Protocole : 58 (0x3a, ICMPv6)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : 3ffe:200:1:3::1 (gw-uni)
ICMPv6
Type : 128 (0x80, Demande d'écho) Code : 0 Checksum : 0xd775
Identificateur : 0x00d6 Numéro de séquence : 0x0000
Données : Date : 0x3469a2a4.000d8c8b Remplissage ...

Le message ICMPv6 d'écho est transmis vers l'adresse Ethernet de <tt>ganesha</tt>, routeur par défaut d'<tt>uma</tt>.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 0:0:c0:86:e2:e9 Type : 86dd
IPv6
Version : 6 Classe : 0x00 Label : 000000
Longueur : 64 octets (0x0040) Protocole : (0x3a, ICMPv6)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : 3ffe:200:1:3::1 (gw-uni)
ICMPv6
Type : 128 (0x80, Demande d'écho) Code : 0 Checksum : 0xd775
Identificateur : 0x00d6 Numéro de séquence : 0x0000
Données : Date : 0x3469a2a4.000d8c8b Remplissage ...

<tt>ganesha</tt> retransmet le paquet IPv6 non modifié vers l'adresse Ethernet de <tt>tuna</tt>, qui est le premier relais sur la route vers la destination finale.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 86dd
IPv6
Version : 6 Classe : 0xf0 Label : 000000
Longueur : 160 octets (0x00a0) Protocole : (0x3a, ICMPv6)
Source : fe80::1800:20ff:fe0c:7a34 (ganesha,lien-local)
Desti. : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
ICMPv6
Type : 137 (0x89, Redirection) Code : 0 Checksum : 0x869d
Meilleur routeur : fe80::200:c0ff:fe86:e2e9 (tuna, lien-local)
Destination : 3ffe:200:1:3::1 (gw-uni)
Options :
Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 00-00-c0-86-e2-e9
Type : 4 (Paquet ayant causé le message) Longueur : 112 octets (0x0e)
Début du paquet IPv6 ayant causé le message

<tt>ganesha</tt> constate que le paquet d'écho a été réémis sur l'interface qui l'avait reçu, et génère donc un message de redirection vers <tt>uma</tt> pour lui indiquer qu'une meilleure route vers <tt>3ffe:200:1:3::1</tt> utilise le routeur <tt>fe80::200:c0ff:fe86:e2e9</tt>.

En IPv6 l'adresse Ethernet du routeur est fournie, ce qui évite une résolution supplémentaire.

Ethernet Src : 8:0:20:a:aa:6d Dst : 0:0:c0:86:e2:e9 Type : 86dd
IPv6
Version : 6 Classe : 0x00 Label : 000000
Longueur : 64 octets (0x0040) Protocole : (0x3a, ICMPv6)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : 3ffe:200:1:3::1 (gw-uni)
ICMPv6
Type : 128 (0x80, Demande d'écho) Code : 0 Checksum : 0xf51f
Identificateur : 0x00d6 Numéro de séquence : 0x0001
Données : Date : 0x3469a2a6.000d6edd Remplissage ...

Le paquet de demande d'écho suivant est envoyé directement vers l'adresse Ethernet de <tt>tuna</tt>.

La table de routage d'<tt>uma</tt> est maintenant :

uma# '''netstat -nrf inet6'''
Routing tables IPv6:
Destination Gateway Flags Refs Use Mtu Interf
default fe80::1800:20ff:fe0c:7a34 UGS 0 17 1500 le0
3ffe:200:1:3::1 fe80::200:c0ff:fe86:e2e9 UGHD 0 2 1500 le0
fe80::200:c0ff:fe86:e2e9 0:0:c0:86:e2:e9 UHDL 1 0 1500 le0
fe80::1800:20ff:fe0c:7a34 1a:0:20:c:7a:34 UHDL 1 2 1500 le0
.....

==Indication de redirection externe==

[[image:Fig5-11.png|thumb|right|400px|Figure 5-11 ''Routage par défaut non optimal'']]

En IPv4, le mécanisme de redirection n'est prévu que pour les machines auxquelles on accède par l'intermédiaire d'un routeur ; la machine émettrice doit connaître les adresses IPv4 directement accessibles (le numéro de réseau correspondant au lien physique), un «ICMP Redirect» ne fonctionne pas pour celles-ci.

En IPv6, il n'est plus nécessaire de connaître tous les préfixes IPv6 correspondant au lien physique, une machine peut se contenter de connaître son adresse, un routeur par défaut, et envoyer tout le trafic inconnu sur ce routeur. Le mécanisme de redirection permettra de rediriger le trafic vers la destination la meilleure dans tous les cas.

Dans l'exemple correspondant à la figure Routage par défaut non optimal, supposons que <tt>guma</tt> a pour adresse globale sur l'interface partagée avec <tt>uma</tt> <tt>3ffe:302:12:4::4</tt>, et que <tt>uma</tt> n'a pas pris en compte dans ses tables de routage que le câble contient des machines appartenant à un préfixe <tt>3ffe:302:12:4::4/64</tt>. Ceci peut être dû au fait que <tt>uma</tt> n'analyse pas tous les préfixes, ou parce que le préfixe n'est pas annoncé sur le câble. Ce cas de figure est courant si le lien reliant <tt>uma</tt> et <tt>guma</tt> est un réseau ATM.

La machine <tt>uma</tt> veut accéder à <tt>guma</tt> :

uma# '''ping6 3ffe:302:12:4::4'''
trying to get source for 3ffe:302:12:4::4
source should be 3ffe:302:12:3:a00:20ff:fe0a:aa6d
PING 3ffe:302:12:4::4: 56 data bytes
64 bytes from 3ffe:302:12:4::4: icmp6_seq=0 ttl=255 time=7.267 ms
.....

Ethernet Src : 8:0:20:a:aa:6d Dst : 1a:0:20:c:7a:34 Type : 86dd
IPv6
Version : 6 Classe : 0x00 Label : 000000
Longueur : 64 octets (0x0040) Protocole : (0x3a, ICMPv6)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : 3ffe:302:12:4::4 (guma)
ICMPv6
Type : 128 (0x80, Demande d'écho) Code : 0 Checksum : 0x43cc
Identificateur : 0x00fd Numéro de séquence : 0x0000
Données : Date : 0x337b4e95.0002725d Remplissage ...

Puisque <tt>uma</tt> ne sait pas que <tt>guma</tt> est directement accessible, le message ICMP d'écho est transmis vers l'adresse Ethernet de <tt>ganesha</tt>, routeur par défaut d'<tt>uma</tt>.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 0:0:c0:89:e2:e6 Type : 86dd
IPv6
Version : 6 Classe : 0x00 Label : 000000
Longueur : 64 octets (0x0040) Protocole : (0x3a, ICMPv6)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : 3ffe:302:12:4::4 (guma)
ICMPv6
Type : 128 (0x80, Demande d'écho) Code : 0 Checksum : 0x43cc
Identificateur : 0x00fd Numéro de séquence : 0x0000
Données : Date : 0x337b4e95.0002725d Remplissage ...

<tt>ganesha</tt> retransmet le paquet non modifié vers <tt>guma</tt>.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 86dd
IPv6
Version : 6 Classe : 0xf0 Label : 000000
Longueur : 160 octets (0x00a0) Protocole : (0x3a, ICMPv6)
Source : fe80::1800:20ff:fe0c:7a34
Desti. : 3ffe:302:12:3:a00:20ff:fe0a:aa6d
ICMPv6
Type : 137 (0x89, Redirection) Code : 0 Checksum : 0xfe45
Meilleur routeur : 3ffe:302:12:4::4 (guma)
Destination : 3ffe:302:12:4::4 (guma)
Options :
Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 00-00-c0-89-e2-e6
Type : 4 (Paquet ayant causé le message) Longueur : 112 octets (0x0e)
Début du paquet IPv6 ayant causé le message

De plus <tt>ganesha</tt> envoie à <tt>uma</tt> un message de redirection. C'est une redirection vers une machine sur le lien physique, ce qui est indiqué par le fait que les champs «Meilleur routeur» et «Destination» sont égaux (le premier relais est la destination finale).

Ethernet Src : 0:0:c0:89:e2:e6 Dst : 8:0:20:a:aa:6d Type : 86dd
IPv6
Version : 6 Classe : 0xf0 Label : 000000
Longueur : 64 octets (0x0040) Protocole : (0x3a, ICMPv6)
Source : 3ffe:302:12:4::4
Desti. : 3ffe:302:12:3:a00:20ff:fe0a:aa6d
ICMPv6
Type : 129 (0x81, Réponse d'écho) Code : 0 Checksum : 0x42cc
Identificateur : 0x00fd Numéro de séquence : 0x0001
Données : Celles de la demande

La réponse de <tt>guma</tt> parvient à <tt>uma</tt> (les messages de sollicitation de voisin échangés ne sont pas montrés dans cet exemple).

Ethernet Src : 8:0:20:a:aa:6d Dst : 0:0:c0:89:e2:e6 Type : 86dd
IPv6
Version : 6 Classe : 0xf0 Label : 000000
Longueur : 64 octets (0x0040) Protocole : (0x3a, ICMPv6)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : 3ffe:302:12:4::4 (guma)
ICMPv6
Type : 128 (0x80, Demande d'écho) Code : 0 Checksum : 0x43be
Identificateur : 0x00fd Numéro de séquence : 0x0001
Données : Date : 0x337b4e96.00027269 Remplissage ...

Les demandes d'écho suivantes sont adressées directement à l'adresse Ethernet de <tt>guma</tt>.
La table de routage d'<tt>uma</tt> est maintenant :

uma# netstat -nrf inet6
Routing tables IPv6:
Destination Gateway Flags Refs Use Mtu Interf
default fe80::1800:20ff:fe0c:7a34 UGS 0 17 1500 le0
3ffe:302:12:4::4 0:0:c0:89:e2:e6 UHDL 0 3 1500 le0
3ffe:200:1:3::1 fe80::200:c0ff:fe86:e2e9 UGHD 0 2 1500 le0
fe80::200:c0ff:fe86:e2e9 0:0:c0:86:e2:e9 UHDL 1 0 1500 le0
fe80::1800:20ff:fe0c:7a34 1a:0:20:c:7a:34 UHDL 1 2 1500 le0
.....

On voit qu'il y a maintenant une ligne avec le drapeau <tt>L</tt> pour la machine <tt>guma</tt>. Le drapeau <tt>L</tt> et l'absence de drapeau <tt>G</tt> indiquent une machine directement accessible, sans routeur intermédiaire.

{{suivi|Découverte de voisins|Découverte de voisins|Configuration automatique|Configuration automatique}}

Découverte de voisins

2007-02-21T11:05:53Z

Bruno Stévant:

{{suivi|Protocoles de Niveau 4|Protocoles de Niveau 4|Exemples de découverte de voisins|Exemples de découverte de voisins}}

__TOC__

Le protocole de découverte des voisins (''neighbor discovery'') permet à un équipement de s'intégrer dans l'environnement local, c'est-à-dire le lien sur lequel sont physiquement transmis les paquets IPv6. Il permet de dialoguer avec les équipements connectés au même support (stations et routeurs). Il ne s'agit pas pour un équipement de connaître exactement la liste de tous les autres équipements connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.

Le protocole utilise cinq types de messages ICMPv6 (voir [[Modèle:Tableau ICMPv6|Valeurs des champs type et code d'ICMPv6]]). Le champ nombre de sauts de l'en-tête IPv6 contient la valeur 255 -- il peut sembler paradoxal d'utiliser une valeur aussi grande pour des datagrammes qui ne doivent pas être routés hors du lien physique ; en fait si un équipement reçoit un datagramme avec une valeur plus petite, cela signifie que l'information provient d'un autre réseau et que le datagramme doit être rejeté.

Le protocole réalise les différentes fonctions :

* Résolution d'adresses. Le principe est très proche du protocole ARP que l'on trouve avec IPv4. La principale différence vient de l'emploi de messages standards ICMPv6 à la place de la définition d'un autre protocole de niveau 3. Cela confère une plus grande souplesse d'utilisation en particulier sur les réseaux qui ne supportent pas la diffusion. Comme pour IPv4, ce protocole construit des tables de mise en correspondance entre les adresses IPv6 et physiques.
* <div id="NUD">Détection d'inaccessibilité des voisins ou NUD (''Neighbor Unreachability Detection''). Cette fonction n'existe pas en IPv4. Elle permet d'effacer des tables de configuration d'un équipement les voisins qui sont devenus inaccessibles (panne, changement d'adresse,...). Si un routeur devient inaccessible, la table de routage peut être modifiée pour prendre en compte une autre route.</div>
* Configuration. La configuration automatique des équipements est l'un des attraits principaux d'IPv6. Plusieurs fonctionnalités du protocole de découverte des voisins sont mises en oeuvre :
** Découverte des routeurs. Ce protocole permet aux équipements de déterminer les routeurs qui sont sur leur lien physique. Dans IPv4, ces fonctionnalités sont assurées par le protocole ICMP Router Discovery.
** Découverte des préfixes. L'équipement apprend le ou les préfixes du réseau en fonction des annonces faites par les routeurs. En y ajoutant l'identifiant d'interface de l'équipement, celui-ci construit son ou ses adresses IPv6. Il n'existe pas d'équivalent pour le protocole IPv4 puisque les adresses sont trop courtes pour faire de l'auto-configuration.
** Détection des adresses dupliquées. Comme les adresses sont construites automatiquement, il existe des risques d'erreurs en cas d'identité de deux identifiants. Ce protocole teste qu'aucun autre équipement sur le lien ne possède la même adresse IPv6. Cette fonctionnalité est une évolution de l'ARP gratuit d'IPv4 émis à l'initialisation de l'interface.
** Découverte des paramètres. Ce protocole permet aux équipements d'apprendre les différents paramètres du lien physique, par exemple, la taille du MTU, le nombre de sauts maximal autorisé (valeur initiale du champ nombre de sauts), si la configuration automatique avec état (comme [[Configuration avec état :DHCPv6|DHCPv6]]) est active... Il n'existe pas d'équivalent en IPv4.
* Indication de redirection. Ce message est utilisé quand un routeur connaît une route meilleure (en nombre de sauts) pour aller à une destination.
:En IPv4 une indication de redirection ne peut servir qu'à corriger l'adresse du routeur utilisé pour accéder à une machine hors du réseau local. Les machines doivent connaître toutes les adresses correspondant aux réseaux locaux.
:Avec IPv6, la correspondance entre préfixe et réseau local est moins stricte. Il est prévu qu'un matériel ne connaisse pas tous les préfixes de son réseau local (si celui-ci est partagé par plusieurs préfixes), ou qu'un préfixe soit partagé entre plusieurs liens (une généralisation du modèle des réseaux logiques d'IP sur ATM). Dans certaines configurations, la machine émettra ses paquets au routeur alors que le destinataire se trouve sur le même segment que l'émetteur. Si c'est le cas, le routeur émettra un message de redirection pour que la suite du dialogue se fasse directement (cf. exemples [[Découverte_de_voisins#IR|Indication de redirection]]).
:Dans le cas le plus extrême, on peut imaginer en IPv6 qu'un équipement peut être configuré pour dialoguer uniquement avec son routeur par défaut. ICMPv6 «redirect» est alors utilisé pour informer l'équipement des destinataires sur le même lien.

= Données véhiculées par les messages =

L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier la plupart des données utilise un format d'options commun, ce qui simplifie la mise en oeuvre du protocole. Le format contient les champs type, longueur en mots de 64 bits, données. La faible précision du champ longueur va introduire une perte de place. En contre-partie, elle va permettre aussi un alignement des options sur des mots de 64 bits, ce qui optimise leur traitement.

En plus des cinq options générales décrites dans le tableau Utilisation des options dans les messages de découverte des voisins, il existe d'autres options spécifiques pour la mobilité et les réseaux NBMA (''Non Broadcast Multiple Access'') comme ATM ou Frame Relay.

{|
|+ Utilisation des options dans les messages de découverte des voisins
| width = 150 | || width = 100 |[[#RS|sollicitation du]] || width = 100 |[[#RA|annonce du]] || width = 100 |[[#NS|sollicitation]] ||width = 100 | [[#NA|annonce]] ||width = 100 |[[#IR|indication de]]
|-
| || [[#RS|routeur]] || [[#RA|routeur]] || [[#NS|d'un voisin]] || [[#NA|d'un voisin]] || [[#IR|redirection]]
|-style="background:silver"
|[[#physique |adresse physique de la source]] || présent || présent || présent || ||
|-
|[[#physique |adresse physique de la cible]] || || || || présent || présent
|-style="background:silver"
|[[#information|information sur le préfixe]] || || ≥ 1 || || ||
|-
|[[#redirigee |en-tête redirigée]] || || || || || présent
|-style="background:silver"
| [[#MTU |MTU]] || || possible || || ||
|}

== <div id="physique">Adresse physique de la source/cible</div> ==

[[image:Fig5-1.png|thumb|right|300px|Figure 5-1 ''Format de l'option adresse physique source/cible'']]

La figure Format de l'option adresse physique source/cible donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.

Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.

== <div id="information">Information sur le préfixe</div> ==

[[image:Fig5-2.png|thumb|right|300px|Figure 5-2 ''Format de l'option information sur le préfixe'']]

Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Le champ type vaut 3 et le champ longueur vaut 4. La figure Format de l'option information sur le préfixe donne le format de l'option :

* Le champ lg.préfixe indique combien de bits sont significatifs pour le préfixe annoncé dans un champ suivant.
* Le bit <tt>L</tt> indique, quand il est à 1, que le préfixe permet d'indiquer que tous les autres équipements partageant le même préfixe sont sur le même lien. L'émetteur peut donc directement les joindre. Dans le cas contraire, l'équipement émet le paquet vers le routeur. Si ce dernier sait que l'équipement émetteur peut joindre directement le destinataire, il émettra un message ICMPv6 d'indication de redirection.
* Le bit <tt>A</tt> indique, quand il est à 1, que le préfixe annoncé peut être utilisé pour construire l'adresse de l'équipement.
* Le bit <tt>R</tt>, indique, quand il est à 1, que le champ préfixe contient l'adresse globale d'un routeur «agent mère». Les bits de poids fort peuvent toujours être utilisés pour construire un préfixe.
* Le champ durée de validité indique en secondes la durée pendant laquelle le préfixe est valide.
* Le champ durée préférable indique la durée en secondes pendant laquelle une adresse construite avec le protocole de configuration sans état demeure «préférable» (cf. [[Plans d'adressage|Durée de vie des adresses]]).

Pour ces deux champs, une valeur de <tt>0xffffffff</tt> représente une durée infinie. Ces champs peuvent servir dans la phase de passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.
* Le champ réservé permet d'aligner le préfixe sur une frontière de mot de 64 bits.
* Le champ préfixe contient la valeur de préfixe annoncé sur le lien. Pour maintenir un alignement sur 64 bits pour le reste des données du paquet, ce champ a une longueur fixe de 128 bits.

== <div id="redirigee">En-tête redirigée</div> ==

[[image:Fig5-3.png|thumb|right|300px|Figure 5-3 ''Format de l'option en-tête redirigée'']]

Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.

Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible.

== <div id="MTU">MTU</div> ==

[[image:Fig5-4.png|thumb|right|300px|Figure 5-4 ''Format de l'option MTU'']]

Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure Format de l'option MTU donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.

Le champ type vaut 5 et le champ longueur 1.

= Messages de découverte de voisins =

Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et un dernier pour la redirection. Chacun de ces messages peut contenir des options.

== <div id="RS">Sollicitation du routeur</div> ==

[[image:Fig5-5.png|thumb|right|300px|Figure 5-5 ''Format des paquets de sollicitation du routeur'']]

Le message de sollicitation d'un routeur (cf. figure Format des paquets de sollicitation du routeur) est émis par un équipement au démarrage pour recevoir plus rapidement des informations du routeur. Ce message est émis à l'adresse IPv6 de multicast réservée aux routeurs sur le même lien <tt>ff02::2</tt>. Si l'équipement ne connaît pas encore son adresse source, l'adresse non spécifiée est utilisée.

Le champ option contient normalement l'adresse physique de l'équipement.

== <div id="RA">Annonce du routeur</div> ==

[[image:Fig5-6.png|thumb|right|300px|Figure 5-6 ''Format des paquets d'annonce du routeur'']]

Ce message (cf. figure Format des paquets d'annonce du routeur) est émis périodiquement par les routeurs ou en réponse à un message de sollicitation d'un routeur par un équipement. Le champ adresse source contient l'adresse locale au lien du routeur, le champ destination contient soit l'adresse de l'équipement qui a émis la sollicitation, soit l'adresse de toutes les stations (<tt>ff02::01</tt>).

Un champ saut max. non nul donne la valeur qui pourrait être placée dans le champ nombre de sauts des paquets émis. Le bit <tt>M</tt> indique qu'une adresse de l'équipement doit être obtenue avec un protocole de configuration (cf. [[Configuration avec état :DHCPv6]]). Le bit <tt>O</tt> indique aussi la présence d'un service de configuration mais pour la récupération d'informations autres que l'adresse. Si l'adresse ne peut être obtenue d'un serveur, l'équipement procède à une configuration sans état en concaténant aux préfixes qu'il connaît son identifiant d'interface. Le bit <tt>H</tt> indique que le routeur peut être utilisé comme «agent mère» pour un noeud mobile (cf. [[Déplacements_des_mobiles#Avertissement_de_l'agent_mère|Avertissement de l'agent mère]]).

Le champ durée de vie du routeur donne, en secondes, la période pendant laquelle l'équipement annonçant effectuera les fonctions de routeur par défaut. La valeur maximale correspond à 18 heures 12 minutes, mais comme ce message est émis périodiquement il n'y a pas de limite théorique à la durée de vie d'un routeur. Une valeur de <tt>0</tt> indique que l'équipement ne remplit pas les fonctions de routeur par défaut. Cette durée de vie ne s'applique pas aux options que ce message véhicule.

Le champ durée d'accessibilité indique la durée en millisecondes pendant laquelle une information contenue dans le cache de la machine peut être considérée comme valide (par exemple, la table de correspondance entre adresse IPv6 et adresse physique). Au bout de cette période, un message de détection d'inaccessibilité est émis pour vérifier la pertinence de l'information.

Le champ temporisation de retransmission donne en millisecondes la période entre deux émissions non sollicitées de ce message. Il sert aux autres équipements pour détecter une inaccessibilité du routeur.

Ce message peut véhiculer les options :

* adresse physique de la source,
* MTU,
* information sur le préfixe (une ou plus).

== <div id="NS">Sollicitation d'un voisin</div> ==

[[image:Fig5-7.png|thumb|right|300px|Figure 5-7 ''Format des paquets de sollicitation d'un voisin'']]

Ce message (cf. figure Format des paquets de sollicitation d'un voisin) permet d'obtenir des informations d'un équipement voisin, c'est-à-dire situé sur le même lien physique (ou connecté via des ponts). Le message peut lui être explicitement envoyé ou émis sur une adresse de diffusion. Dans le cas de la détermination de l'adresse physique, il correspond à la requête ARP du protocole IPv4.

Le champ adresse source du paquet IPv6 contient soit l'adresse locale au lien adresse lien-local, soit une adresse globale, soit l'adresse non spécifiée. Le champ destination contient soit l'adresse de multicast sollicité correspondant à l'adresse recherchée (cf. [[Adressage_multicast#Identifiant_de_groupe|Identifiant de groupe]]), soit l'adresse de l'équipement (dans le cas d'une détection d'inaccessibilité des voisins, NUD )

Le champ adresse de la cible contient l'adresse IPv6 de l'équipement cherché. Le champ option contient en général l'adresse physique de la source.

== <div id="NA">Annonce d'un voisin</div> ==

[[image:Fig5-8.png|thumb|right|300px|Figure 5-8 ''Format des paquets d'annonce d'un voisin'']]

Ce message (cf. figure Format des paquets d'annonce d'un voisin) est émis en réponse à une sollicitation, mais il peut aussi être émis spontanément pour propager une information de changement d'adresse physique, ou de statut «routeur». Dans le cas de la détermination d'adresse physique, il correspond à la réponse ARP pour le protocole IPv4.

* Le bit <tt>R</tt> est mis à 1 si l'émetteur est un routeur. Ce bit est utilisé pour permettre la détection d'un routeur qui redevient un équipement ordinaire.
* Le bit <tt>S</tt> mis à 1 indique que cette annonce est émise en réponse à une sollicitation.
* Le bit <tt>O</tt> mis à 1 indique que cette annonce doit effacer les informations précédentes qui se trouvent dans les caches des autres équipements, en particulier la table contenant les adresses physiques.
* Le champ adresse de la cible contient, si le bit <tt>S</tt> est à 1, la valeur du champ adresse de la cible de la sollicitation auquel ce message répond. Si le bit <tt>S</tt> est à 0, ce champ contient l'adresse IPv6 lien-local de l'équipement émetteur.
* L'option adresse physique de la cible contient l'adresse physique de l'émetteur.

== <div id="IR">Indication de redirection</div> ==

La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure Routage par défaut non optimal).

[[image:Fig5-9.png|thumb|right|300px|Figure 5-9 ''Format des paquets d'indication de redirection'']]

Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe.

La figure Format des paquets d'indication de redirection donne le format du message :

* Le champ adresse cible contient l'adresse IPv6 de l'équipement vers lequel les paquets doivent être émis.
* Le champ adresse destination contient l'adresse IPv6 de l'équipement pour lequel la redirection s'applique.

Dans le cas de la redirection vers un équipement se situant sur le même lien, l'adresse cible et la destination sont identiques.

Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé.

{{suivi|Protocoles de Niveau 4|Protocoles de Niveau 4|Exemples de découverte de voisins|Exemples de découverte de voisins}}

Déplacements des mobiles

2007-02-21T10:54:44Z

Bruno Stévant: /* Avertissement de l'agent mère */

{{suivi| La gestion de la mobilité IPv6 | La gestion de la mobilité IPv6 | Les en-têtes de mobilité | Les en-têtes de mobilité }}
La raison d'être de Mobile IPv6 est de gérer les déplacements des mobiles. Pour cela il faut être capable de détecter les changements de réseau, d'obtenir une nouvelle CoA, et informer l'agent mère et les correspondants du changement de localisation (i.e. de CoA). L'ensemble de ces opérations sont regroupées dans le "handover".

===Détection du changement de réseau===

La phase de détection de mouvement est cruciale. Elle représente une bonne part du délai d'interruption observé lors des changements de réseau. Le mobile utilise la gestion de voisinage pour détecter qu'un voisin, en l'occurrence son routeur par défaut, n'est plus accessible. Le défaut de ce mécanisme est que le mobile ne détecte la perte du routeur par défaut que lorsqu'il a des données à transmettre, ce qui retarde la détection du changement de réseau et augmente d'autant la durée des interruptions.

Une solution alternative suppose la coopération du routeur IPv6 qui ajoute dans les [[Découverte de voisins#RA|annonces de routeur]] une option indiquant le délai entre deux annonces. Le mobile qui écoute en permanence les annonces émises peut alors déduire de la perte de plusieurs annonces successives qu'il vient probablement de changer de réseau. Une autre adaptation demandée au routeur IPv6 concerne la réduction du délai entre deux annonces successives pour améliorer encore la vitesse de détection, ainsi il est conseillé d'émettre une annonce de routeur non sollicité toutes les 50 ms en moyenne (au lieu de 3s). Évidemment une telle configuration induit un trafic non négligeable pour certains types de réseau (réseau locaux sans fil).

Il est important de réduire le nombre de ''handover'' car ceux-ci induisent une rupture temporaire des communications et une signalisation importante dans le réseau. Le mobile peut utiliser d'autres informations pour décider de la nécessité d'effectuer un handover, mais il doit le faire prudemment. Par exemple, le mobile ne peut pas utiliser la découverte d'un nouveau réseau (une annonce de routeur avec un nouveau préfixe) pour décider qu'il a perdu l'accès à son ancien réseau. Il est, en effet, possible de recevoir simultanément des annonces en provenance de plusieurs routeurs annonçant des préfixes différents sur un même réseau.

Lorsqu'il reçoit une annonce de routeur, le mobile doit prendre en compte le préfixe annoncé et non l'adresse source des annonces de routeur pour détecter un changement, car des routeurs appartenant à des réseaux différents peuvent utiliser la même adresse lien-local. Dans ce cas, le bit <tt>R</tt> qui permet d'indiquer une adresse globale du routeur peut lever l'ambiguïté.

Notons que les mécanismes de détection de changement de réseau décrits sont complètement indépendants du niveau liaison. Il est possible de prendre en compte les informations connues du niveau liaison, comme le fait que le mobile vient de perdre ou d'acquérir un nouveau réseau sans-fils ou une nouvelle interface, pour déclencher la procédure du handover IPv6. Emettre une [[Découverte de voisins#RS|sollicitation de routeur]] aussitôt qu'un changement de réseau d'accès est soupçonné, permet de gagner un temps important mais suppose une implémentation plus complexe, puisque dépendante d'un niveau liaison particulier. En contrepartie, il est possible d'éviter l'envoi fréquent d'annonces de routeur non sollicitées.

===Configuration de l'adresse temporaire===

Une fois que le mobile a détecté la perte du routeur par défaut, il doit acquérir une nouvelle adresse en sollicitant un routeur. A réception d'une annonce de routeur sur le nouveau réseau il peut découvrir le préfixe du réseau et configurer une adresse globale appartenant à ce préfixe qui sera la nouvelle adresse temporaire (CoA). Lors de cette configuration, le mobile doit effectuer une procédure de [[Configuration automatique#DAD|détection d'adresse dupliquée]] (DAD) pour la nouvelle adresse. Sous certaines conditions, on cherchera à réduire la durée de cette procédure en émettant la sollicitation de voisin sans attendre le délai aléatoire habituel. D'autres proposition ont été faites pour ne pas attendre la seconde réglementaire qu'une éventuelle station défendant l'adresse réponde à la sollicitation de voisin.

Notons que le mobile peut configurer une adresse pour chaque préfixe annoncé sur le [[Lien-local|lien local]]. Toutes ces adresses seront des care-of address. Mais il devra choisir l'une d'entres-elles pour mettre à jour les associations au niveau du HA et des correspondants. Elle sera dite primary care-of address ou adresse temporaire primaire.

===<div id="Avertissement_Agent_Mere">Avertissement de l'agent mère===

Dès que le mobile a changé de care-of address principale, il doit en informer l'agent mère en envoyant une mise à jour d'association (''binding update''). Cette mise à jour peut être la première, dans ce cas, l'agent mère crée l'association. Dans le cas contraire, il met à jour l'association courante. Une mise à jour d'association, sera par la suite envoyée régulièrement, avant le délai d'expiration, pour maintenir l'association.

Lorsqu'il crée une nouvelle association, l'agent mère effectue la procédure de détection de duplication d'adresse (DAD) pour la home address avant d'acquitter l'association au mobile. Si un autre mobile ou une station sur le réseau mère possède cette adresse il répond au mobile que l'adresse est déjà utilisés et ce dernier doit essayer une autre adresse.

===Découverte dynamique de l'agent mère===

Il peut arriver que le mobile ne connaisse pas l'adresse d'un agent mère sur son réseau mère ou que l'agent mère qu'il connaissait ne réponde plus. Dans ce cas, le mobile doit tenter de découvrir l'adresse d'un agent mère apte à assumer ce rôle pour lui. Il envoie pour cela un paquet ICMP à l'adresse anycast des "Agents mère IPv6" pour le préfixe de son réseau mère.

Lorsque le mobile reçoit une réponse celle-ci contient une liste ordonnée des adresses globales des HAs du réseau mère. Il essaye ensuite dans l'ordre les adresses des agents mère de la liste jusqu'à recevoir un acquittement positif à sa demande de mise à jour d'association.

[[image:Fig13-9.png|thumb|right|500px|Figure 13-9 ''Découverte dynamique de l'agent mère'']]

Pour supporter ce service, chaque HA doit être capable de découvrir les autres HAs sur le réseau mère pour en maintenir la liste. Il écoute pour cela les [[Découverte de voisins#RA|annonces de routeur]] émises sur le lien. Celles qui annoncent offrir le service d'agent mère (bit H : ''Home Agent'' validé) sont ajoutées à la liste. L'annonce de HA peut contenir d'autres informations utiles dans l'option home agent advertisement option : le délai de validité (''lifetime''), une adresse globale et une préférence. Cette dernière est utilisée pour ordonner la liste transmise au mobile.

Dans l'exemple, figure Découverte dynamique de l'agent mère, la requête ICMP du mobile atteint l'agent mère 1 mais ce denier renvoie une liste indiquant que l'agent mère 2 est plus prioritaire. Le mobile continuera donc la procédure en demandant à l'agent mère 2 d'enregistrer l'association.

Ce mécanisme pourra être implémenté pour distribuer la fonction d'agent mère sur plusieurs serveurs et pour répartir dynamiquement la charge entre les différents serveurs. La charge des agents mère est un point très critique de la mobilité IP et il est nécessaire de trouver des solutions permettant de résister au facteur d'échelle.

===Interception des paquets par l'agent mère===

L'agent mère doit assurer l'interception des paquets à destination du mobile dès qu'il dispose d'une association entre l'adresse mère (HoA) et une adresse temporaire (CoA) valide. Pour cela il diffuse une [[Découverte de voisins#NA|annonce de voisin]] non sollicitée sur le réseau mère. Cette annonce indique aussi que toutes les tables de voisinage doivent être mise à jour pour associer la HoA du mobile avec l'adresse de niveau 2 de l'agent mère. Comme le multicast n'est pas fiabilisé ce message est généralement émis plusieurs fois.

Ensuite, à chaque fois qu'une [[Découverte de voisins#NS|sollicitation de voisin]] concerne la HoA d'un mobile qu'il gère, le HA répond en lieu et place du mobile, pour associer la HoA du mobile avec son adresse de niveau 2. Il assure ainsi la défense de la HoA enregistrée dans l'association lors des procédures de détection de duplication d'adresse. Il répondra qu'il possède l'adresse si un autre mobile ou une autre station du réseau mère tente de la configurer.

Lorsque le HA a des paquets à transmettre au mobile, il doit agir comme un correspondant. Il utilise donc un en-tête de routage de type 2. Si par contre il s'agit de paquet qu'il intercepte pour le compte du mobile, ils sont encapsulés en utilisant l'encapsulation IP dans IP et envoyés à destination de l'adresse temporaire du mobile. Ce dernier traite ces paquets comme tout paquet disposant d'un en-tête de tunnelage. C'est-à-dire qu'il supprime l'en-tête externe et traite le paquet IP contenu comme s'il était arrivé directement.

L'agent mère ne fait pas suivre les paquets émis à destination de l'adresse [[Lien-local|lien local]] du mobile. Ceux-ci sont détruits et un message ICMP annonçant l'indisponibilité du mobile est envoyé à la source, sauf dans le cas du multicast ou le paquet est silencieusement écarté.

===Information des correspondants===

En acquittant la mise à jour d'association l'agent mère informe le mobile qu'il possède une association en règle et ce dernier peut informer ses correspondants. Pour cela il effectue la procédure [[Sécurisation de la signalisation avec les noeuds correspondants|RR]] (Return Routability Procedure - Procédure de test de Routage Retour) qui sera vue plus loin puis la mise à jour d'association. Il doit le faire pour tous les correspondants qui sont dans la liste des associations qu'il maintient.

===Gestion de l'adresse mère===

La validité de l'adresse mère, comme celle des autres adresses IPv6, est limitée dans le temps. La limite vient de la durée de validité annoncée dans l'annonce de routeur contenant le préfixe. Lorsqu'une adresse mère approche de sa date de péremption, le mobile ne peut pas envoyer tout simplement de [[Découverte de voisins#RS|sollicitation de routeur]] s'il n'est pas dans le réseau mère. Dans ce cas il émet un message appelé "sollicitation de préfixe mobile", directement vers l'agent mère. Ce message est semblable à une sollicitation de routeur, mais il contient l'option d'en-tête destination home address. Il doit être protégé par IPsec comme la plupart des échanges entre le mobile et l'agent mère. Ce dernier répond à la sollicitation par une annonce de préfixe mobile ressemblant à une annonce de routeur et dont les éléments seront traités par le mobile comme si l'annonce avait été reçue sur le réseau mère. En particulier le préfixe du réseau mère permet de mettre à jour la durée de validité de l'adresse mère.

Ce mécanisme permet de supporter la renumérotation du réseau mère. En effet, lorsque le mobile reçoit un nouveau préfixe, il peut configurer une nouvelle adresse mère en utilisant les mécanismes habituels d'auto configuration sans état.

===Retour dans le réseau mère===

Lorsqu'il détecte qu'il est de retour dans le réseau mère, le mobile doit en informer l'agent mère pour que ce dernier cesse de faire suivre les paquets à l'ancienne localisation du mobile. Il utilise pour détecter son retour dans le réseau mère une annonce de routeur contenant le préfixe de sa home address.

Pour envoyer la mise à jour d'association à l'agent mère, le mobile doit connaître l'adresse de niveau 2 de l'agent mère ce qui peut être déduit de l'annonce de routeur. Toutefois, il peut y avoir plusieurs agents mère sur le réseau. Dans ce cas le mobile doit découvrir l'adresse de niveau 2 de l'agent mère sans utiliser sa home address puisque l'agent mère est configuré pour la défendre dans les procédures de détection d'adresse dupliquée. Il demande donc l'adresse de niveau 2 de l'agent mère en émettant une sollicitation de voisin avec comme adresse source l'adresse non définie (<tt>::</tt>). Par contre il doit utiliser la home address comme adresse source de la mise à jour d'association et être en mesure de recevoir l'acquittement qui sera transmis par l'agent mère à cette adresse. Il doit donc configurer préalablement son interface avec la home address sans effectuer de procédure de détection d'adresse dupliquée.

Dès que la procédure de mise à jour d'association est terminée le mobile peut diffuser une annonce de voisin indiquant qu'il reprend possession de sa home address à toutes les autres stations sur le réseau local. Le bit indiquant la sollicitation devra être à zéro, tandis que celui indiquant que toutes les stations doivent mettre à jour leur cache avec la nouvelle association sera mis à 1. Ce message sera émis plusieurs fois pour prévenir les pertes éventuelles sur le réseau local. Une fois cette procédure terminée il doit supprimer les associations maintenues par les correspondants pour toutes les associations qu'il maintient.
{{suivi| La gestion de la mobilité IPv6 | La gestion de la mobilité IPv6 | Les en-têtes de mobilité | Les en-têtes de mobilité }}

Talk:Exemples d'extensions

2007-02-20T21:08:30Z

Bruno Stévant:

la longueur de l'extension dans la fragmentation n'est pas conforme au desassemblage

Merci, c'est corrigé -- BS

Exemples d'extensions

2007-02-20T21:07:39Z

Bruno Stévant: /* Exemple de fragmentation */

{{suivi |Les extensions|Les extensions|Checksum au niveau transport|Checksum au niveau transport}}

== Exemple de routage par la source ==
Le paquet suivant a été capturé lors de l'ouverture d'une connexion telnet. La commande telnet permet de spécifier des paramètres de routage par la source. Ainsi <tt>telnet @routeur1@destination</tt> permet un routage libéral vers la destination en passant par le routeur intermédiaire routeur1.

IPv6
Version : 6 Classe : 00 Label : 00000
Longueur : 64 octets (0x0040) Protocole : 43 (0x2b) En-tête de routage
Nombre de sauts : 64 (0x40)
Source : 3ffe:302:12:2::13
Desti. : 3ffe:302:12:5:2a0:c9ff:feaa:2201 (routeur1)
Routage
En-tête Suivant : 06 (0x06) TCP
Longueur Extension : 0x02 => 128 bits
Type de routage = 0x00 (Routage par la source)
Segments restant : 0x01. Réservé 0x00
Réservé : 0x00000000
Adresse suivante : 3ffe:305:1002:1:200:c0ff:fe11:cba0 (destination)
TCP
Port Source, 0xffb1 Port Destination :0x0017 (Telnet)
Sequence : 0x17107e57 Acquittement : 0x00000000
Offset : 0xa Drapeau : 0x02 (SYN) Fenêtre : 0x4000
Checksum : 0x356e Ptr Msg Urgent : 0x0000
Options TCP

''0000: 6<font color="blue">0 0</font>0 00 00 <font color="blue">00 40</font> 2b <font color="blue">40</font> 3f fe 03 02 00 12 00 02''
''0010: 00 00 00 00 00 00 00 13 <font color="blue">3f fe 03 02 00 12 00 05</font>''
''0020: <font color="blue">02 a0 c9 ff fe aa 22 01</font>|06 <font color="blue">02</font> 00 <font color="blue">01</font> 00 00 00 00''
''0030: <font color="blue">3f fe 03 05 10 02 00 01 02 00 c0 ff fe 11 cb a0</font>|''
''0040: ff b1 00 17 17 10 7e 57 00 00 00 00 a0 02 40 00''
''0050: 35 6e 00 00 02 04 05 a0 01 03 03 00 01 01 08 0a''
''0060: 00 9a 1d 04 00 00 00 0b''

Dans l'en-tête IPv6, le numéro de protocole <tt>0x2b</tt> indique qu'une extension de routage est insérée. Noter que le champ longueur des données utiles prend en compte la longueur de l'extension. Le champ adresse de destination de l'en-tête IPv6 contient l'adresse du routeur intermédiaire.

La partie extension commence par l'encapsulation suivante, ici <tt>0x06</tt> pour TCP. Le champ suivant (<tt>0x02</tt>) donne la longueur de l'extension en mots de 64 bits. La partie données contient donc une seule adresse IPv6. Il s'agit de la destination. Le type de routage vaut <tt>0</tt> et le champ segment restant vaut <tt>1</tt> et pointe vers l'adresse de destination.

== Exemple de fragmentation ==

Les paquets suivants correspondent à l'envoi d'un datagramme de longueur 3 500 octets en UDP alors que le MTU de l'interface est 1 500.

IPv6
Version : 6 Classe : 00 Label : 00000
Longueur : 1456 octets (0x05b0) Proto. : 44 (0x2c) En-tête de frag.
Nombre de sauts : 64 (0x40)
Source : 3f fe 03 02 00 12 00 02 00 00 00 00 00 00 00 13
Desti. : 3f fe 03 02 00 12 00 05 02 a0 c9 ff fe aa 22 01
Fragmentation
En-tête Suivant : 17 (0x11) UDP
Longueur Extension : 0x02 => 128 bits
Place du Fragment : 0x0000 bit M =1
Identificateur : 0x0000008e
UDP
Port Source : 0xf38e Port Destination : 0x000d
Longueur : 3508 (0x0db4) Checksum : 0xc227

''0000: 6<font color="blue">0 0</font>0 00 00 <font color="blue">05 b0</font> 2c <font color="blue">40</font> 3f fe 03 02 00 12 00 02''
''0010: 00 00 00 00 00 00 00 13 <font color="blue">3f fe 03 02 00 12 00 05</font>''
''0020: <font color="blue">02 a0 c9 ff fe aa 22 01</font>|11 <font color="blue">02</font> 00 01 <font color="blue">00 00 00 8e</font>|''
''0030: f3 8e 00 0d 0d b4 c2 27 30 31 32 33 34 35 36 37''
''0040: 38 39 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e''
''0050: 4f 50 51 52 53 54 55 56 57 58 59 5a 61 62 63 64''
''0060: 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74''
''0070: ...''

Le bit <tt>M</tt> de l'option de fragmentation est à <tt>1</tt>, un autre fragment va suivre.

IPv6
Version : 6 Classe : 00 Label : 00000
Longueur : 1456 octets (0x05b0) Proto. : 44 (0x2c) En-tête de frag.
Nombre de sauts : 64 (0x40)
Source : 3f fe 03 02 00 12 00 02 00 00 00 00 00 00 00 13
Desti. : 3f fe 03 02 00 12 00 05 02 a0 c9 ff fe aa 22 01
Fragmentation
En-tête Suivant : 17 (0x11) UDP
Longueur Extension : 0x02 => 128 bits
Place du Fragment : 0x05a8 bit M =1
Identificateur : 0x0000008e

''0000: 6<font color="blue">0 0</font>0 00 00 <font color="blue">05 b0</font> 2c <font color="blue">40</font> 3f fe 03 02 00 12 00 02''
''0010: 00 00 00 00 00 00 00 13 <font color="blue">3f fe 03 02 00 12 00 05</font>''
''0020: <font color="blue">02 a0 c9 ff fe aa 22 01</font>|11 <font color="blue">02</font> 05 a9 <font color="blue">00 00 00 8e</font>|''
''0030: 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54''
''0040: 55 56 57 58 59 5a 61 62 63 64 65 66 67 68 69 6a''
''0050: 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 7a''
''0060: 30 31 32 33 34 35 36 37 38 39 41 42 43 44 45 46''
''0070: 47 48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56''
''0080: ...''

Ce fragment est la suite du précédent puisque la valeur de l'identificateur est la même (<tt>0x0000008e</tt>), le bit <tt>M</tt> étant à 1, d'autres fragments vont suivre. Le champ Place du fragment contient 1 448. Si l'on prend en compte la taille des extensions (8 octets), on retrouve bien la taille des informations utiles (1 456) transportées dans le paquet précédent.

{{suivi |Les extensions|Les extensions|Checksum au niveau transport|Checksum au niveau transport}}

Les extensions

2007-02-20T21:00:45Z

Bruno Stévant: /* <div id="routage">Routage */

{{suivi |Justification des extensions|Justification des extensions|Exemples d'extensions|Exemples d'extensions}}

__NOTOC__

Les extensions d'IPv6 peuvent être vues comme un prolongement de l'encapsulation d'IP dans IP. À part l'extension de proche-en-proche traitée par tous les routeurs intermédiaires, les autres extensions ne sont prises en compte que par les équipements destinataires du paquet.

Une extension a une longueur multiple de 8 octets. Elle commence par un champ en-tête suivant d'un octet qui définit le type de données qui suit l'extension : une autre extension ou un protocole de niveau 4 (voir tableau Valeurs du champ en-tête suivant). Pour les extensions à longueur variable, l'octet suivant contient la longueur de l'extension en mots de 8 octets, le premier n'étant pas compté (une extension de 16 octets a un champ longueur de 1).

{{Valeurs du champ en-tête suivant}}

Le RFC 2460 recommande l'ordre suivant :

*[[#PeP|Proche-en-proche]] (doit toujours être en première position)
*[[#dest|Destination]] (sera aussi traité par les routeurs listés dans l'extension de routage par la source)
*[[#routage|Routage]] par la source
*[[#frag|Fragmentation]]
*Authentification
*Destination (traité uniquement par l'équipement terminal)

== <div id=PeP> Proche-en-proche </div> ==

[[image:Fig4-6.png|thumb|right|350px|Figure 4-6 ''Format générique des options "proche-en-proche" et "destination"'']]

Cette extension (en anglais : ''hop-by-hop'') se situe toujours en première position et est traitée par tous les routeurs que le paquet traverse. Le type associé (contenu dans le champ d'en-tête en-tête suivant de l'en-tête précédent) est 0 et le champ longueur de l'extension contient le nombre de mots de 64 bits moins 1.

L'extension est composée d'options. Pour l'instant, seules quatre options, dont deux de bourrage, sont définies (cf. Format des options IPv6). Chaque option est une suite d'octets. Le premier octet est un type, le deuxième (sauf pour l'option 0) contient la longueur de l'option moins 2. Les deux premiers bits de poids fort du type définissent le comportement du routeur quand il rencontre une option inconnue :

*00 : le routeur ignore l'option ;
*01 : le routeur rejette le paquet ;
*10 : le routeur rejette le paquet et retourne un message ICMPv6 d'inaccessibilité ;
*11 : le routeur rejette le paquet et retourne un message ICMPv6 d'inaccessibilité si l'adresse de destination n'est pas multicast.

Le bit suivant du type indique que le routeur peut modifier le contenu du champ option (valeur à 1) ou non (valeur à 0).

[[image:Fig4-7.png|thumb|right|350px|Figure 4-7 ''Format des options IPv6'']]

Les quatre options de proche-en-proche sont :

*<div id="Pad1">Pad1 (type 0). Cette option est utilisée pour introduire un octet de bourrage.</div>
*<div id="Padn">Padn (type 1). Cette option est utilisée pour introduire plus de 2 octets de bourrage. Le champ longueur indique le nombre d'octets qui suivent.</div>

Les options de bourrage peuvent sembler inutiles avec IPv6 puisqu'un champ longueur pourrait en donner la longueur exacte. En fait les options de bourrage servent à optimiser le traitement des paquets en alignant les champs sur des mots de 32, voire 64 bits ; le RFC 2460 discute en annexe de la manière d'optimiser le traitement tout en minimisant la place prise par les options.

*Jumbogramme (type 194 ou 0xc2, RFC 2675). Cette option est utilisée quand le champ longueur des données du paquet IPv6 n'est pas suffisant pour coder la taille du paquet. Cette option est essentiellement prévue pour la transmission à grand débit entre deux équipements. Si l'option jumbogramme est utilisée, le champ longueur des données utiles dans l'en-tête IPv6 vaut 0. <br> Noter que le type commence par la séquence binaire 11, ce qui permet au routeur ne traitant pas les jumbogrammes d'en informer la source. Celle-ci pourra réémettre l'information sans utiliser cette option.

*L'option Router Alert (RFC 2711) demande à un routeur d'examiner le contenu des données qu'il relaie (Router Alert existe également en IPv4, RFC 2113). En principe, le processus de relayage (recopier le paquet sur une interface de sortie en fonction de l'adresse destination et des tables de routage) doit être le plus rapide possible. Mais pour des protocoles comme la gestion des groupes de multicast avec MLD (''Multicast Listener Discovery'') ou la signalisation des flux avec RSVP, tous les routeurs intermédiaires doivent tenir compte des données. <br>L'émetteur envoie les données à la destination, mais s'il précise l'option Router Alert, les routeurs intermédiaires vont analyser les données, voire modifier leur contenu avant de relayer le paquet. Ce mécanisme est efficace puisque les routeurs n'ont pas à analyser le contenu de tous les paquets d'un flux. <br> Le type de l'option vaut 5. Il commence par la séquence binaire 00, puisqu'un routeur qui ne connaît pas cette option doit relayer le paquet sans le modifier. Le champ valeur de l'option contient :
**0 : pour les messages du protocole MLD de gestion des groupes multicast ;
**1 : pour les messages RSVP ;
**2 : pour les réseaux actifs ;
:les autres valeurs sont réservées.

== <div id=dest>Destination </div>==
Cette extension, dont le format est identique à l'extension de proche-en-proche (cf. figure Format des extensions "proche-en-proche" et "destination"), contient des options qui sont traitées par l'équipement destinataire. Pour l'instant, à part les options de bourrage (voir [[#Pad1|Pad1]] et [[#Padn|Padn]]) et de mobilité (cf. [[Mobilité dans IPv6]]), la seule autre option concerne le tunnelage dans des paquets IPv6 (RFC 2473). Cette option permet de limiter le niveau d'encapsulation dans des tunnels des paquets IPv6.

== <div id="routage">Routage ==
Cette extension permet d'imposer à un paquet une route différente de celle offerte par les politiques de routage présentes sur le réseau. Pour l'instant seul le routage par la source (type = 0), similaire à l'option ''Loose Source Routing'' d'IPv4, est défini pour IPv6. La [[Mobilité dans IPv6|mobilité IPv6]] a également introduit une extension de routage (type = 2) (cf. [[La gestion de la mobilité IPv6#Optimisation dans le cas du mobile dans un réseau étranger|Optimisation dans le cas du mobile dans un réseau étranger]]).

Dans IPv4, le routage peut être strict (le routeur suivant présent dans la liste doit être un voisin directement accessible) ou libéral (''loose'') (un routeur peut utiliser les tables de routage pour joindre le routeur suivant servant de relais). Dans IPv6, seul le routage libéral est autorisé. En effet, le routage strict était initialement mis en place surtout pour des raisons de sécurité. La source devait être absolument sûre du chemin pris par les paquets. Cette utilisation a maintenant disparu du réseau.

Le principe du routage par la source ou Source Routing dans IPv4 est rappelé en introduction de ce chapitre sur les extensions. Le principe est le même pour IPv6. L'émetteur met dans le champ destination du paquet IPv6, l'adresse du premier routeur servant de relais, l'extension contient la suite de la liste des autres routeurs relais et le destinataire. Quand un routeur reçoit un paquet qui lui est adressé comportant une extension de routage par la source, il permute son adresse avec l'adresse du prochain routeur et réémet le paquet vers cette adresse suivante.

[[image:Fig4-8.png|thumb|right|350px|Figure 4-8 ''Format de l'extension routage par la source'']]

La figure Format de l'extension routage par la source donne le format de l'extension de routage par la source :

*Le champ longueur de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de type 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2.
*Le champ type indique la nature du routage. Pour l'instant, seul le routage par la source, de type 0 est spécifié. La suite de l'en-tête correspond à ce type.
*Le nombre de segments restant est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée.
*Les 32 bits suivants sont inutilisés pour préserver l'alignement.

La liste comprenant les routeurs à traverser et le destinataire est fournie. Ces adresses ne peuvent pas être multicast.

== <div id="frag">Fragmentation </div>==

La fragmentation telle qu'elle est pratiquée dans IPv4 n'est pas très performante. Initialement, elle servait à rendre transparente les limitations physiques des supports de transmission. Dans IPv4 quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille et si le bit <tt>DF</tt> (''don't fragment'') est à 0, il découpe l'information à transmettre en fragments. Or le réseau IP étant un réseau à datagramme, il n'y a pas de possibilité de contrôler les fragments. Deux fragments successifs peuvent prendre deux chemins différents et par conséquent seul le destinataire peut effectuer le réassemblage. En conséquence, après la traversée d'un lien impliquant une fragmentation, le reste du réseau ne voit passer que des paquets de taille réduite.

Il est plus intéressant d'adapter la taille des paquets à l'émission. Ceci est fait en utilisant les techniques de découverte du MTU (voir [[Mécanisme de découverte du PMTU]] (RFC 1981)). En pratique une taille de paquets de 1 500 octets est presque universelle.

Il existe pourtant des cas où la fragmentation est nécessaire. Ainsi une application telle que NFS sur UDP suppose que la fragmentation existe et produit des messages de grande taille. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation. Pour réduire le travail des routeurs intermédiaires, la fragmentation se fera chez l'émetteur et le réassemblage chez le récepteur.

[[image:Fig4-9.png|thumb|right|350px|Figure 4-9 ''Format de l'extension de fragmentation'']]

Le format de l'extension de fragmentation est donné figure Format de l'extension de fragmentation. La signification des champs est identique à celle d'IPv4 :

*Le champ <tt>place du fragment</tt> indique lors du réassemblage où les données doivent être insérées. Ceci permet de parer les problèmes dus au déséquencement dans les réseaux orientés datagrammes. Comme ce champ est sur 13 bits, la taille de tous les segments, sauf du dernier, doit être multiple de 8 octets.
*Le bit <tt>M</tt> s'il vaut 1 indique qu'il y aura d'autres fragments émis.
*Le champ <tt>identification</tt> permet de repérer les fragments appartenant à un même paquet initial. Il est différent pour chaque paquet et recopié dans ses fragments.
*Le bit <tt>DF</tt> (''don't fragment'') n'est plus nécessaire puisque, si un paquet est trop grand, il y aura rejet du paquet par le routeur.

Dans IPv4, la valeur d'une option était codée de manière à indiquer au routeur effectuant la fragmentation si elle devait être copiée dans les fragments. Dans IPv6, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant proche-en-proche, routage par la source) sont recopiées dans chaque fragment.

== Sécurité ==
Deux extensions de sécurité -- les extensions d'authentification AH (''Authentication Header'') et de confidentialité ESP (''Encapsulating Security Payload'') -- sont définies par l'IETF. Elles permettent de protéger les communications passées sur les réseaux IPv6 mais aussi IPv4 en assurant les services de confidentialité, authentification, intégrité et détection de rejeux. Le chapite [[Sécurité]], RFC 2402 donne une description détaillée de ces extensions, et présente les modes de protection existants.

{{suivi |Justification des extensions|Justification des extensions|Exemples d'extensions|Exemples d'extensions}}

IPv6

2007-02-20T20:49:54Z

Bruno Stévant:

{{suivi |Anycast|Anycast|Justification des extensions|Justification des extensions}}

Hormis la modification de la taille des adresses, ce qui conduit à une taille d'en-tête de 40 octets (le double de l'en-tête IPv4 sans les options), le protocole IP a subi un toilettage reprenant l'expérience acquise au fil des ans avec IPv4. Le format des en-têtes IPv6 est simplifié et permet aux routeurs de meilleures performances dans leurs traitements :

* L'en-tête ne contient plus le champ checksum, qui devait être ajusté par chaque routeur en raison de la décrémentation du champ durée de vie. Par contre, pour éviter qu'un paquet dont le contenu est erroné -- en particulier sur l'adresse de destination -- ne se glisse dans une autre communication, tous les protocoles de niveau supérieur doivent mettre en œuvre un mécanisme de checksum de bout en bout incluant un pseudo-en-tête qui prend en compte les adresses source et destination. Le checksum d'UDP, facultatif pour IPv4, devient ainsi obligatoire. Pour ICMPv6, le checksum intègre le pseudo-en-tête, alors que pour ICMPv4, il ne portait que sur le message ICMP.
* La taille des en-têtes est fixe. Le routeur peut facilement déterminer où commence la zone de données utiles.
* Les options ont été retirées de l'en-tête et remplacées par de nouveaux en-têtes appelés extensions qui peuvent être facilement ignorées par les routeurs intermédiaires.
* Les champs sont alignés sur des mots de 64 bits, ce qui optimise leur traitement, surtout avec les nouvelles architectures à 64 bits.
* La taille minimale des MTU : Maximum Transmission Unit est de 1 280 octets. Le choix de 1 280 comme MTU minimal en IPv6 permet le tunnelage de paquets IPv6. En effet, la taille de 1 500 octets est généralement admise car elle correspond à la valeur imposée par Ethernet. La majorité des autres réseaux offrent une taille supérieure. La valeur de 576 octets retenue pour IPv4 permettait de prendre en compte des réseaux comme Appletalk. Pour ces réseaux, une couche d'adaptation (comme avec les couches d'adaptation AAL d'ATM) devra être mise en oeuvre pour pouvoir transporter les paquets IPv6.
* La fonction de fragmentation a été retirée des routeurs. Les champs qui s'y reportent (identification, drapeau, place du fragment) ont été supprimés. Normalement les algorithmes de découverte du [[Mécanisme de découverte du PMTU|PMTU]](Path MTU) évitent d'avoir recours à la fragmentation. Si celle-ci s'avère nécessaire, une extension est prévue (voir [[Les_extensions#frag|Fragmentation]]).

Le format d'en-tête d'un paquet IPv6 est donné par le RFC 2474 (cf. Format d'un datagramme IPv6).

[[image:Fig4-1.png|thumb|left|300px|Figure 4-1 ''Format d'un datagramme IPv6'']]

; Version : Le champ version est le seul champ qui occupe la même place dans le paquet IPv6 et dans le paquet IPv4. Sa valeur est 6.

; [[Classe de trafic]] :

; [[Identificateur de flux]] :

; Longueur des données utiles (payload) :Contrairement à IPv4, ce champ, sur deux octets, ne contient que la taille des données utiles, sans prendre en compte la longueur de l'en-tête. Pour des paquets dont la taille des données serait supérieure à 65 535 ce champ vaut 0 et l'option jumbogramme de l'extension de "proche-en-proche" est utilisée (cf. [[Les_extensions#PeP|Jumbogramme]]) (type 194 ou 0xc2, RFC 2675 ). Cette option est utilisée quand le champ longueur des données du paquet IPv6 n'est pas suffisant pour coder la taille du paquet. Cette option est essentiellement prévue pour la transmission à grand débit entre deux équipements. Si l'option jumbogramme est utilisée, le champ longueur des données utiles dans l'en-tête IPv6 vaut 0. Noter que le type commence par la séquence binaire 11, ce qui permet au routeur ne traitant pas les jumbogrammes d'en informer la source. Celle-ci pourra réémettre l'information sans utiliser cette option.).

;En-tête suivant : Ce champ a une fonction similaire au champ protocole du paquet IPv4. Il identifie le prochain en-tête. Il peut s'agir d'un protocole (de niveau supérieur ICMP, UDP, TCP...) ou de la désignation d'extensions (cf. tableau Valeurs du champ en-tête suivant).

{{Valeurs du champ en-tête suivant}}

Les extensions contiennent aussi ce champ pour permettre un chaînage.

; Nombre de sauts : Il est décrémenté à chaque n?ud traversé. Un datagramme retransmis par un routeur est rejeté avec l'émission d'un message d'erreur ICMPv6 vers la source si la valeur après décrémentation atteint 0. <br> Dans IPv4 ce champ est appelé durée de vie (ou TTL Time To Live). Sa vocation initiale est d'indiquer, en secondes, la durée maximale durant laquelle un paquet peut rester dans le réseau. En pratique, les paquets ne restent que quelques millisecondes dans les routeurs, et donc la décrémentation est arrondie à 1. Par contre, pour une liaison plus lente la décrémentation de ce champ peut être supérieure à 1. Dans IPv6, comme il s'agit d'un nombre de sauts, la décrémentation est toujours de 1. <br>La valeur initiale de ce champ devrait être donnée dans un document annexe de l'IANA (http://www.iana.org/) ce qui permettrait de la modifier en fonction de l'évolution de la topologie du réseau. La valeur n'est pas encore officiellement attribuée, mais certaines implantations prennent actuellement la valeur conseillée pour IPv4 : 64. <br>La valeur par défaut peut être dynamiquement attribuée aux équipements du réseau par les annonce des routeurs (cf. [[Configuration automatique]]), une modification de ce paramètre sera donc relativement simple quand la limite actuelle sera atteinte. On peut noter une limitation, puisque ce champ codé sur 8 bits n'autorise la traversée que de 255 routeurs. En réalité, dans l'Internet actuel, le nombre maximal de routeurs traversés est d'une quarantaine, ce qui laisse une bonne marge pour l'évolution du réseau.

== Exemples ==

Le paquet IPv6 suivant a été capturé au cours d'une connexion FTP :

''0000: 6<font color="blue">0 0</font>0 00 00 <font color="blue">00 28</font> 06 <font color="blue">40</font> 3f fe 03 02 00 12 00 02''
''0010: 00 00 00 00 00 00 00 13 <font color="blue">3f fe 03 05 10 02 00 01</font>''
''0020: <font color="blue">02 00 c0 ff fe 11 cb a0</font>|ff b3 <font color="blue">00 15</font> 55 4d fd d1''
''0030: <font color="blue">00 00 00 00</font> a0 <font color="blue">02</font> 40 00 <font color="blue">7d 76</font> 00 00 <font color="blue">02 04 05 a0</font>''
''0040: <font color="blue">01</font> 03 03 00 <font color="blue">01</font> 01 <font color="blue">08 0a 00 9a 17 44 00 00 00 00</font>''

Le paquet commence par <tt>6</tt> qui indique la version du protocole. Le second champ <tt><font color="blue">00</font></tt> donne la classe de trafic ''DiffServ''. L'identificateur de flux n'a pas été défini par la source (<tt>0 00 00</tt>). La longueur du paquet est de <tt><font color="blue">0x0028</font></tt> octets. Le paquet ne contient pas d'extension puisque la valeur de l'en-tête suivant, <tt>0x06</tt>, correspond au protocole de niveau 4 TCP. Le nombre maximal de routeurs que le paquet pourra traverser est de 64 (<tt><font color="blue">0x40</font></tt>). Les adresses source et destination sont des adresses de test appartenant au plan d'adressage agrégé.

{{suivi |Anycast|Anycast|Justification des extensions|Justification des extensions}}

Identifiant d'interface

2007-02-20T18:58:45Z

Bruno Stévant: /* Manuel */

{{suivi |Lien-local|Adresses Lien-local|Site-local|Site-local}}

Les types d'adresses global ou lien-local utilisent un identifiant sur 64 bits pour désigner une interface connectée sur un lien. Si cette longueur n'est pas directement imposée par la norme d'adressage d'IPv6 RFC 3513, elle bénéficie d'un fort consensus car elle permet de garantir facilement une unicité sur le lien et par conséquent de faciliter l'auto-configuration des équipements.

Plusieurs techniques ont été élaborées à l'IETF. La plus répandue est basée sur l'utilisation d'une valeur unique par construction comme l'adresse MAC de la machine. Mais l'on peut également choisir une valeur aléatoire pour garantir plus de confidentialité ou au contraire la dériver d'une clé publique pour mieux authentifier l'émétteur du message. La taille de 64 bits permet de réduire à une valeur proche de zéro la probabilité de conflits. Enfin dans certains cas l'affectation manuelle de cette valeur peut se justifier.

Les chapitres suivants décrivent ces différentes méthodes ainsi que leur intérêts et leur défauts.

== Différents types d'identifiants d'interface==
=== EUI-64 ===

L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 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 :

[[image:Fig3-8.png|thumb|right|350px|Figure 3-8 ''identificateur global IEEE EUI-64'']]

* 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. <br>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.
: 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.

[[image:Fig3-9.png|thumb|right|350px|Figure 3-9 ''Identificateur d'interface dérivé d'une EUI-64'']]

* 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>.

[[image:Fig3-10.png|thumb|right|350px|Figure 3-10 ''Transformation d'une adresse MAC en identifiant d'interface'']]

* Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou FDDI), cette adresse est utilisée pour construire des identifiants d'interface sur 64 bits, comme indiqué sur la figure ci-contre.
: A 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 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.
* 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. <br>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.

=== Manuel ===

L'utilisation de l'adresse MAC pour construire l'adresse IP de la machine peut conduire dans certains cas à des problèmes de configuration, en particulier si la machine est un serveur. En effet, s'il l'on change la carte Ethernet de l'équipement (voire l'équipement) l'adresse IPv6 qui en dépend change également.

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 machine 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 resolveur DNS une adresse manuelle.

=== Valeur aléatoire ===

L'identifiant d'interface tel qu'il a été défini 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.

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.

L'adresse publique globale est conservée, mais ne sera jamais choisie pour initier des communications. Elle permettra par contre d'en recevoir, même si l'anonymat est validé.

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.

Ces identifiants privés ne sont pas incompatibles avec les identifiants publics. Une machine peut attendre des ouvertures de connexions sur ses adresses publiques, par contre initier les connexions en utilisant ses identifiants privés. Il suffit de considérer que les adresses publiques sont dépréciées pour une durée indéterminée.

[[image:Fig3-A.png|thumb|right|350px|''Configuration des interfaces sous Windows'']]

La figure Configuration des interfaces sous Windows illustre cette propriété, en retournant le résultat de la commande <tt>ipconfig</tt>. On peut noter que l'interface du réseau sans-fils possède trois adresses IPv6 (une lien locale et deux globales). Les adresses globales possèdent le même préfixe de 64 octets (<tt>2001:660:7307:6030::/64</tt>). La première adresse globale a le bit <tt>u=0</tt> dans l'identifiant d'interface, il s'agit de celle générée aléatoirement. La deuxième à le bit <tt>u</tt> à <tt>1</tt> et l'on retrouve la séquence <tt>0xFFFE</tt> au milieu de l'identifiant d'interface; cette adresse est dérivée de l'adresse MAC. Sous Windows, par défaut, les adresses aléatoires ont une durée de vie d'une semaine. Par exemple, en utilisant la commande <tt>netsh</tt> :

netsh interface ipv6>'''show address'''
Recherche du statut actif...

Interface 7 : Connexion réseau sans fil

Type adr. État DAD Vie valide Vie préf. Adresse
--------- --------- ---------- ---------- -----------------------------------
Temporaire Préféré 6d21h18m38s 21h15m51s 2001:660:7307:6030:c853:e48b:aafb:c354
Public Préféré 29d23h58m59s 6d23h58m59s 2001:660:7307:6030:204:e2ff:fe5a:9f
Liaison Préféré infinite infinite fe80::204:e2ff:fe5a:9f

=== Cryptographique ===

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.

==Selection du type d'identifiant d'interface==

Si l'on sélectionne correctement le type d'identifiant d'interface, la gestion de l'adressage IPv6 est aussi facile (voire plus simple) qu'en IPv6. Ainsi, il est préférable de donner aux serveurs des identifiants d'inteface construit manuellement. Il sera ainsi beaucoup plus facile de se rappeler de leur adresse. De plus si l'équipement est remplacé et par conséquent que la carte réseau est différente, l'adresse IPv6 restera stable. Pour les clients, il est plus simple d'utiliser l'identifiant d'interface construit à partir de l'adresse MAC.

{{suivi |Lien-local|Adresses Lien-local|Site-local|Site-local}}

Identifiant d'interface

2007-02-20T18:58:26Z

Bruno Stévant: /* Manuel */

Unicast Global

2007-02-20T18:37:36Z

Bruno Stévant: /* Adresses gérées par les RIR */

{{suivi |Plans d'adressage|Plans d'adressage|Lien-local|Adresses Lien-local}}

=== 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. Une adresse intègre trois niveaux de hiérarchie :

[[image:Fig3-3.png|thumb|right|350px|Figure 3-4 ''Adresse de type plan agrégé'']]

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

Il existe plusieurs instanciations de ce plan d'adressage. Historiquement la première (préfixe <tt>3FFE::/16</tt>) a servi aux réseaux expérimentaux, puis une seconde (préfixe <tt>2001::/16</tt>) est définie par les autorités régionales pour les réseaux dits de production, enfin une troisième est dédiée (préfixe <tt>2002::/16</tt>) au mécanisme de transition [[Déploiement IPv6 des fournisseurs d'accès (ISP)#6to4|6to4]]. Ces instanciations sont différenciées par la valeur du préfixe initial de 16 bits (cf. Tableau). Très récemment, d'autres préfixes ont été libérés. 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. Il semble que cela pourrait remettre en cause l'attribution de préfixes de longueur 48 pour tous les utilisateurs au profit de préfixes plus long. Une version, à jour des allocations est disponible sur le site http://www.iana.org/assignments/ipv6-unicast-address-assignments.

== Adresses de test ==

Les expérimentations d'IPv6 sur un réseau devaient commencer avant que les règles d'attribution des préfixes soient complètement finalisées. La valeur 0x1FFE a été attribué par l'IANA au 6bone dans le plan d'adressage agrégé pour les expérimentations (RFC 3701). Il correspond au préfixe <tt>3FFE::/16</tt> pour l'ensemble du 6bone.

[[image:Fig3-4.jpg|thumb|right|350px|Figure 3-4 ''Adresse de test du plan agrégé'']]

Les 48 bits restant avant le champ Subnet ID recréent les niveaux hiérarchiques d'un réseau IPv6 défini dans le RFC 3587, d'où le terme pseudo accolé au nom du champ. La taille réduite n'étant pas un facteur limitant dans la phase expérimentale. Des pseudo-TLA d'une taille initialement de 8, mais portées à 12 bits par la suite, sont attribués à des opérateurs voulant expérimenter le protocole. Les 24 ou 20 bits suivants sont utilisés pour numéroter les sites.

Les pseudo-TLA ont été alloués jusqu'en décembre 2003 aux opérateurs qui en faisaient la demande. La liste complète est disponible sur le serveur Web http://www.6bone.net/6bone_pTLA_list.html. Le tableau Pseudo TLA attribués par le groupe ngtrans reprend quelques unes de ces valeurs.

{|
|+'''''Pseudo TLA attribués par le groupe ngtrans'''''
!Organismes/Pays!!Préfixe!! !!Organismes/Pays!!Préfixe
|-style="background:silver"
|ROOT66/US-CA||3FFE:0000::/24|| ||TRUMPET/AU||3FFE:8000::/28
|-
|TELEBIT/DK||3FFE:0100::/24|| ||ICM-PL/PL||3FFE:8010::/28
|-style="background:silver"
|SICS/SE||3FFE:0200::/24|| ||IIJ/JP||3FFE:8020::/28
|-
|G6/FR||3FFE:0300::/24|| ||QTPVSIX/EU||3FFE:8030::/28
|-style="background:silver"
|JOIN/DE||3FFE:0400::/24|| ||APAN-KR||3FFE:8040::/28
|-
|WIDE/JP||3FFE:0500::/24|| ||MIBH||3FFE:8050::/28
|-style="background:silver"
|SURFNET/NL||3FFE:0600::/24|| ||ATNET-AT||3FFE:8060::/28
|}

L'expérimentation lié au 6bone s'est terminée récemment; la date d'arrêt a été symboliquement choisie le mardi 6 juin 2006 RFC 3701. En effet, si ce réseau a servi palier à l'absence d'opérateurs officiels au début de l'introduction d'IPv6, il a vite montré ses limites. L'utilisation de tunnels pour créer la connectivité a conduit à un trop fort maillage, à des routes relativement longues et par conséquence à une faible qualité de service.

== Adresses gérées par les RIR ==

La valeur <tt>0x0001</tt> a été attribué par l'IANA pour un plan d'adressage où les autorités régionales attribuent les préfixes. Le préfixe initial est par conséquent <tt>2001::/16</tt>. Ce plan reproduit, en étendant la largeur des champs les principes de délégation et de gestion introduits en IPv4 par CIDR. Un site voulant se connecter reçoit de son fournisseur d'accès un préfixe global de longueur supérieure ou égale à 48 bits.

{{suivi |Plans d'adressage|Plans d'adressage|Lien-local|Adresses Lien-local}}

Unicast Global

2007-02-20T18:36:27Z

Bruno Stévant: /* Adresses de test */

{{suivi |Plans d'adressage|Plans d'adressage|Lien-local|Adresses Lien-local}}

=== 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. Une adresse intègre trois niveaux de hiérarchie :

[[image:Fig3-3.png|thumb|right|350px|Figure 3-4 ''Adresse de type plan agrégé'']]

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

Il existe plusieurs instanciations de ce plan d'adressage. Historiquement la première (préfixe <tt>3FFE::/16</tt>) a servi aux réseaux expérimentaux, puis une seconde (préfixe <tt>2001::/16</tt>) est définie par les autorités régionales pour les réseaux dits de production, enfin une troisième est dédiée (préfixe <tt>2002::/16</tt>) au mécanisme de transition [[Déploiement IPv6 des fournisseurs d'accès (ISP)#6to4|6to4]]. Ces instanciations sont différenciées par la valeur du préfixe initial de 16 bits (cf. Tableau). Très récemment, d'autres préfixes ont été libérés. 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. Il semble que cela pourrait remettre en cause l'attribution de préfixes de longueur 48 pour tous les utilisateurs au profit de préfixes plus long. Une version, à jour des allocations est disponible sur le site http://www.iana.org/assignments/ipv6-unicast-address-assignments.

== Adresses de test ==

Les expérimentations d'IPv6 sur un réseau devaient commencer avant que les règles d'attribution des préfixes soient complètement finalisées. La valeur 0x1FFE a été attribué par l'IANA au 6bone dans le plan d'adressage agrégé pour les expérimentations (RFC 3701). Il correspond au préfixe <tt>3FFE::/16</tt> pour l'ensemble du 6bone.

[[image:Fig3-4.jpg|thumb|right|350px|Figure 3-4 ''Adresse de test du plan agrégé'']]

Les 48 bits restant avant le champ Subnet ID recréent les niveaux hiérarchiques d'un réseau IPv6 défini dans le RFC 3587, d'où le terme pseudo accolé au nom du champ. La taille réduite n'étant pas un facteur limitant dans la phase expérimentale. Des pseudo-TLA d'une taille initialement de 8, mais portées à 12 bits par la suite, sont attribués à des opérateurs voulant expérimenter le protocole. Les 24 ou 20 bits suivants sont utilisés pour numéroter les sites.

Les pseudo-TLA ont été alloués jusqu'en décembre 2003 aux opérateurs qui en faisaient la demande. La liste complète est disponible sur le serveur Web http://www.6bone.net/6bone_pTLA_list.html. Le tableau Pseudo TLA attribués par le groupe ngtrans reprend quelques unes de ces valeurs.

{|
|+'''''Pseudo TLA attribués par le groupe ngtrans'''''
!Organismes/Pays!!Préfixe!! !!Organismes/Pays!!Préfixe
|-style="background:silver"
|ROOT66/US-CA||3FFE:0000::/24|| ||TRUMPET/AU||3FFE:8000::/28
|-
|TELEBIT/DK||3FFE:0100::/24|| ||ICM-PL/PL||3FFE:8010::/28
|-style="background:silver"
|SICS/SE||3FFE:0200::/24|| ||IIJ/JP||3FFE:8020::/28
|-
|G6/FR||3FFE:0300::/24|| ||QTPVSIX/EU||3FFE:8030::/28
|-style="background:silver"
|JOIN/DE||3FFE:0400::/24|| ||APAN-KR||3FFE:8040::/28
|-
|WIDE/JP||3FFE:0500::/24|| ||MIBH||3FFE:8050::/28
|-style="background:silver"
|SURFNET/NL||3FFE:0600::/24|| ||ATNET-AT||3FFE:8060::/28
|}

L'expérimentation lié au 6bone s'est terminée récemment; la date d'arrêt a été symboliquement choisie le mardi 6 juin 2006 RFC 3701. En effet, si ce réseau a servi palier à l'absence d'opérateurs officiels au début de l'introduction d'IPv6, il a vite montré ses limites. L'utilisation de tunnels pour créer la connectivité a conduit à un trop fort maillage, à des routes relativement longues et par conséquence à une faible qualité de service.

== Adresses gérées par les RIR ==

La valeur <tt>0x0001</tt> a été attribué par l'IANA pour un plan d'adressage où les autorités régionales attribuent les préfixes. Le préfixe initial est par conséquent <tt>2001::/16</tt>. Ce plan reproduit, en étendant la largeur des champs les principes de délagation et de gestion introduits en IPv4 par CIDR. Un site voulant se connecter reçoit de son fournisseur d'accès un préfixe global de 48 bits.

{{suivi |Plans d'adressage|Plans d'adressage|Lien-local|Adresses Lien-local}}

Introduction

2007-02-20T17:07:22Z

Bruno Stévant: /* Principes fondamentaux d'IP */

{{suivi |Préambule|Préambule|Adressage|Adressage}}

= Principes fondamentaux d'IP =

L'Internet connaît un succès très important, bien au-delà des prévisions les plus optimistes faites à l'époque de sa conception. Les raisons de ce succès sont multiples ; on peut cependant essayer d'en dégager quelques-unes, tenant aux caractéristiques fondamentales de l'Internet et à l'architecture du protocole de communication IP (''Internet Protocol'') utilisé.

L'Internet est bâti sur un modèle de réseau de réseaux. Son nom vient d'ailleurs de l'anglais ''Inter Networking''. On ne fait aucune hypothèse sur le type d'infrastructure ou d'équipement utilisés. Les extrémités, ou points de connexion aux réseaux, sont des objets capables de traitements évolués. Les données sont véhiculées dans des datagrammes séparés (que l'on appelle communément paquets). À partir de ces prémisses, les architectes de l'Internet ont retenu deux principes fondamentaux : la communication de "bout en bout" et le "meilleur effort" (''Best Effort'') pour l'acheminement.

Le principe du "bout en bout" implique que les partenaires d'une communication dialoguent depuis chaque extrémité du réseau pour établir et gérer leur communication. Les éléments intermédiaires sont transparents et n'interviennent pas dans le dialogue. Les objets d'extrémité étant "intelligents", ils sont à même de prendre les décisions nécessaires. Il n'y a pas de position intrinsèquement privilégiée sur le réseau : chaque ordinateur connecté à l'Internet a les mêmes potentialités. Ceci permet aussi une extension du modèle client/serveur : un serveur n'est plus forcément lié à un équipement particulier puisque tout ordinateur connecté à l'Internet peut devenir serveur et n'importe quel autre ordinateur peut en devenir client. C'est cette caractéristique qui a rendu possible la prolifération des serveurs Web dans le monde entier. N'importe qui possédant un ordinateur connecté à l'Internet peut en effet installer son propre serveur Web. Elle est également fondamentale pour les applications peer to peer.

Le principe du "meilleur effort" dit que les éléments d'interconnexion n'offrent aucune garantie sur l'acheminement des données. Ils se contentent de faire "de leur mieux" pour les acheminer. Par exemple, les paquets de données peuvent ne pas emprunter deux fois de suite le même chemin, certains peuvent se perdre en route, d'autres arriver dans le désordre, même si cela est relativement rare dans l'Internet...

C'est ce principe qui fait dire qu'IP n'est pas un protocole "fiable" mais par contre "robuste". Il n'est pas "fiable" au sens où l'arrivée des données envoyées n'est pas garantie. Les réseaux, ainsi libérés d'une tâche très complexe, peuvent dynamiquement se reconfigurer en cas de panne d'une liaison ou d'un équipement. Les protocoles de niveau transport comme TCP se chargent de la gestion des réémissions des données perdues et du réassemblage de celles arrivées dans le désordre ; ils fournissent ainsi la "fiabilité" du service.

Ces deux principes permettent de s'affranchir des différences entre les supports et entre matériels d'interconnexion utilisés. Ce sont eux qui ont rendu possible la croissance de l'Internet que l'on connaît aujourd'hui. Cette croissance est maintenant freinée par deux problèmes majeurs : le manque d'adresses disponibles et la stabilité due à la taille des tables de routage des équipements d'interconnexion des opérateurs réseaux.

Les ordinateurs sont identifiés dans l'Internet par des adresses IP uniques. Le principe du datagramme impose que l'adresse de destination se retrouve dans l'ensemble des paquets émis sur le réseau. Pour permettre un traitement très rapide, les routeurs doivent trouver rapidement cette adresse. Dans IPv4, ces adresses sont codées dans un mot binaire de 32 bits et se retrouvent toujours à la même place dans l'en-tête. Ce principe d'ingénierie a montré son efficacité puisqu'il permet de construire des équipements d'interconnexion simple traitant un nombre important de paquets à la seconde.

Une adresse codée sur 32 bits permet théoriquement d'adresser 2^32 machines, soit à peu près 4 milliards. Ce nombre pourrait paraître au premier abord très élevé, mais les ordinateurs ne sont pas numérotés séquentiellement. Ils sont regroupés par réseaux. À chaque réseau est affecté un numéro qui est codé sur une partie des 32 bits de l'adresse des machines. On s'aperçoit alors que le nombre de réseaux disponibles n'est pas si important que cela conduit à une pénurie. La tendance actuelle consiste à freiner au maximum l'allocation des adresses réseaux. Ce n'est pas un problème pour les sites déjà équipés disposant déjà de larges plages d'adresses. Cette contrainte est déjà forte pour les nouveaux sites dans les pays dits "développés" pour lesquels un grand nombre d'adresses a été réservé mais se révèle être un problème majeur pour les pays émergeants où parfois moins de 10 réseaux de 250 machines ont été attribués pour l'ensemble du pays.

Les équipements d'interconnexion des réseaux, orientant les paquets vers leur destination finale, sont des routeurs. Pour prendre leurs décisions, ils consultent une table dite de routage. Le nombre de réseaux dans l'Internet croissant de manière vertigineuse, ces tables de routage deviennent de plus en plus volumineuses et difficiles à maintenir. Pour pallier ce problème, une solution d'adressage hiérarchique permettent de réunir un ensemble de numéros de réseaux contigus en un seul préfixe a été conçue (CIDR : ''Classeless Inter Domain Routing''). En plus de la réduction des tables de routage, CIDR permet aussi de réduire la sur-allocation d'adresses aux sites terminaux, réduisant quelque peu la pénurie d'adresses. Avec CIDR le propriétaire de l'adresse est modifié. Dans les plans d'adressage initiaux, le site était propriétaire de son préfixe, avec CIDR le préfixe devient la propriété de son opérateur, rendant la renumérotation du réseau nécessaire, si le site change d'opérateur. Cet adressage hiérarchique a montré son efficacité opérationnelle et les règles d'adressage actuelles pour IPv6 généralisent ce principe.

Un autre palliatif à la pénurie est le recours à la traduction d'adresses (NAT : ''Network Address Translator'') utilisant des adresses "privées" à l'intérieur d'un site. Ces adresses ne permettent pas de communiquer directement avec une machine connectée à l'Internet. Les communications avec l'extérieur étant quand même nécessaires, on a recours à un artifice pour les réaliser : le routeur de sortie de site "convertit" toutes les adresses privées en une ou plusieurs adresses officielles. Ce routeur établit donc les communications en lieu et place des machines internes au site.

Un tel mécanisme ne nécessite que quelques adresses IP officielles pour l'ensemble d'un site pouvant contenir plusieurs milliers de machines. Cette approche est une violation manifeste du principe de connexion de bout en bout. Elle est suffisante pour utiliser des applications simples comme l'accès au Web mais pénalise lourdement la mise en place de nombreuses autres applications. De plus, elle interdit la mise en oeuvre de solutions à forte sécurité basées sur la cryptographie.

En résumé, ces mécanismes provisoires figent le réseau pour une utilisation dans un mode dit client/serveur. Les clients sont à l'intérieur de l'entreprise dans un Internet "privé" et les serveurs sont à l'extérieur sur l'Internet "public". Or ce paradigme est remis en cause par de nouvelles applications, comme le fax et la téléphonie sur Internet où chaque équipement doit être autorisé à recevoir des appels. De même pour les particuliers, les jeux répartis en réseau sont promis à un succès certain. Or, ils ne fonctionnent pas avec des mécanismes de traduction d'adresses, car les applications doivent s'échanger leur adresses.

Le succès d'un réseau n'est pas uniquement lié aux bons choix technologiques adoptés lors de la conception du protocole. Il est aussi lié aux services et aux applications disponibles sur ce réseau. IP joue ce rôle unificateur à la frontière entre des supports de transmission et des applications. Plus qu'une indépendance entre l'application et le médium, le réseau permet aux applications de communiquer entre les différents médias. Le risque à maintenir trop longtemps des adressages privés est de rompre cette communication entre différents mondes, créant la richesse du réseau. Elle pourrait même conduire chaque monde à développer un protocole réseau plus adapté à son besoin propre au détriment de l'interconnectivité.

Il était devenu impératif de s'attaquer simultanément à ces deux problèmes d'épuisement des adresses disponibles et d'explosion des tables de routage en s'appuyant sur les principes fondamentaux qui ont fait la réussite de l'Internet. C'est à cette tâche que depuis 1992 s'est attelé l'IETF (Internet Engineering Task Force), l'organisme de standardisation de l'Internet, pour définir le protocole IPv6.

Après plus de 10 ans d'efforts de standardisation, les spécifications de base du protocole et les règles d'attribution des adresses sont clairement définies. La plupart des routeurs et des systèmes d'exploitation incluent cette nouvelle version du protocole IP. Il reste maintenant à faire sortir IPv6 des laboratoires et des plate-formes d'expérimentation, à assurer l'interopérabilité avec IPv4 quand cela est nécessaire et à développer de nouvelles applications profitant de cette espace d'adressage quasi-illimité qu'offre IPv6. Un des défis dans les années à venir est d'utiliser IPv6 dans des domaines jusque là ignorés des réseaux (audio-visuel, domotique, automobile,...).

{{suivi |Préambule|Préambule|Adressage|Adressage}}

Préambule

2007-02-20T17:03:34Z

Bruno Stévant: /* L'auteur */

{{suivi |Accueil|Accueil|Introduction|Introduction}}

Dès le début des années 1990, l'évolution du réseau Internet semblait compromise à très court terme, car la conception du protocole IP (Internet Protocol) limitait le nombre d'équipements qui pouvaient s'y connecter. A l'origine, en 1973, ce réseau ne devait servir qu'à relier une centaine de machines. En fait, de nombreuses catégories d'utilisateurs sont très vite venues s'y joindre. Ce furent tout d'abord les scientifiques et les universitaires ; puis, en 1992, le réseau fut ouvert aux activités commerciales avec le succès que l'on sait. L'Internet n'avait pas été prévu pour supporter la croissance exponentielle du nombre d'équipements connectés. Le réseau a menacé d'atteindre la saturation et certains ont prédit son effondrement total en 1994. Comme toute prédiction de ce genre, elle s'est révélée fausse. En effet, dès 1993, des mesures d'urgence avaient été prises. Cela a permis de retarder l'échéance de quelques années. Les ingénieurs et chercheurs travaillant au sein de l'organisme de standardisation de l'Internet ont mis à profit ce délai pour concevoir une nouvelle version du protocole, s'affranchissant des limites imposées par l'actuelle version. Pour éviter toute confusion, la version initiale est désormais appelée IPv4. La version 5 ayant déjà été attribuée à un protocole expérimental, la version issue de ces travaux a été baptisée IPv6.

Ces travaux ont été l'occasion de spécifier les formats et mécanismes nécessaires pour prendre en compte les avancées issues des recherches sur les réseaux menées depuis 25 ans. Elles portent notamment sur l'auto-configuration, la mobilité, la diffusion multi-points, la sécurité (authentification de l'émetteur de l'information et chiffrement des données).

Les travaux principaux concernant IPv6 sont maintenant terminés. De nombreuses implantations sont disponibles aussi bien pour les équipements d'interconnexion que les ordinateurs. Les règles d'attribution des adresses IPv6 sont précisées et les opérateurs commencent à déployer des réseaux de production.

Cet ouvrage fait le point sur les travaux autour de la standardisation d'IPv6, sur ce qui peut être actuellement testé, les problèmes rencontrés au cours du développement, les pistes envisagées pour les résoudre et les sujets qui sont encore du domaine de la recherche. Il s'adresse aussi bien à des étudiants de troisième cycle qu'à des ingénieurs soucieux de préparer l'évolution de leurs réseaux. Cet ouvrage peut servir de référence sur cette nouvelle version du protocole IP en donnant de nombreux exemples tirés de cas réels.

Après une [[Introduction]] expliquant pourquoi le changement de protocole est devenu nécessaire et les principes fondamentaux qui ont été conservés dans IPv6, l'[[Adressage]] présente les différents types d'adresses ([[Lien-local|locale au lien]], [[Unicast Global|globale]], multicast et [[Anycast|anycast]]) et les plans d'adressage test et opérateur.

Le chapitre [[IPv6|Protocoles réseau et transport]] décrit en détail la nouvelle pile de protocoles, le protocole ICMPv6, le protocole MLD utilisé pour la gestion locale des groupes multicast et les modifications à apporter aux protocoles de niveaux supérieurs.

Le chapitre [[Découverte de voisins|Configuration automatique et contrôle]] traite des mécanismes de configuration automatique sans état et des mécanismes de découverte de voisins.

Le chapitre [[Nommage]] s'intéresse aux relations avec les mécanismes de haut niveau nécessaires pour faire la configuration automatique. En particulier les changements apportés au DNS pour prendre en compte les spécifications propres à IPv6.

Le chapitre [[Supports de transmission]] explique le transport d'IPv6 sur différents supports (Ethernet, LLP, PPP, tunnels et UMTS).

Le chapitre [[Installation d'un équipement]] détaille l'insertion des équipements dans un réseau IPv6. Il décrit comment activer et configurer la pile protocolaire des systèmes d'exploitation les plus répandus (Solaris, Windows, AIX, Linux, *BSD,...).

Le chapitre [[Routage]] est consacré aux routage. Il présente les différents protocoles utilisés pour IPv6 (RIPng, OSPF, IS-IS et BGP 4+). Le chapitre [[Configuration des routeurs]] donne des exemples de configuration des routeurs les plus couramment utilisés.

Le chapitre [[Multicast]] traite du multicast IPv6, définit plus en détail le format d'adresses et décrit les protocoles de routages utilisés.

Le chapitre [[Sécurité]] explique les mécanismes de sécurité définis pour IP. Il traite des différentes architectures et des échanges de clés.

Le chapitre [[Mobilité dans IPv6]] traite ensuite des aspects liés à la mobilité.

Le chapitre [[Intégration d'IPv6 et des applications]] s'intéresse aux problèmes de transitions d'IPv4 vers IPv6. Il présente les différents mécanismes ainsi que des scénarios de déploiement.

Enfin, l'interface de programmation est présentée au chapitre [[Programmation d'applications]] (comment utiliser la résolution de nom dans un programme, comment programmer un serveur traitant à la fois des requêtes IPv4 et IPv6, comment programmer des applications réseau comme ping ou comment programmer des applications multicasts).

En annexe, le lecteur trouvera l'[[Historique de la standardisation d’IPv6|historique d'IPv6]] depuis sa genèse, ainsi qu'un rappel du fonctionnement des instances de standardisation de l'Internet (appelé IETF), la [[bibliographie]] détaillée et la structure et l'utilisation des bases whois.

== Le Groupe français d'expérimentateurs IPv6 (G6) ==

L'idée du G6 est née d'une rencontre en novembre 1995 entre Alain Durand de l'IMAG (Institut d'Informatique et de Mathématiques Appliquées de Grenoble) et Bernard Tuy de l'UREC (Unité REseau du CNRS) pour regrouper les actions de différents développeurs et expérimentateurs IPv6 en France. À cette époque, seuls quelques "illuminés" avaient entendu parler d'IPv6 mais, déjà, une implantation réalisée par Francis Dupont de l'INRIA (Institut National de Recherche en Informatique et en Automatique) était disponible.

Le groupe G6 s'est constitué avec des partenaires universitaires et industriels. Autour du noyau originel, se sont retrouvées des personnes venant des Universités de Bordeaux, Lille, Nantes, Paris, Strasbourg, des Écoles Nationales Supérieures de Télécommunications de Bretagne et de Paris, de l'Institut Pasteur, de Bull, d'Alcatel et de 6Wind. Des réunions sont régulièrement organisées dans les différents lieux d'expérimentation.

Outre le partage d'expérience, la participation aux groupes de travail de l'IETF et la participation aux réunions RIPE (Réseaux IP Européens), le groupe s'est donné pour objectif de diffuser largement les connaissances acquises. Cet ouvrage en est la concrétisation majeure et de nombreux séminaires ont été organisés en France et en Europe. Un autre aspect très important des travaux du G6 est la mise en place du réseau G6bone pour relier en IPv6 les différents sites d'expérimentation. Ce réseau est bien sûr partie intégrante du réseau 6bone.

On trouvera plus d'informations sur http://www.g6.asso.fr/.

== L'auteur ==

Au risque de décevoir ses admirateurs, Gisèle Cizault n'existe que dans l'esprit des membres de G6, qui regroupe les utilisateurs français d'IPv6. Les personnes qui ont contribué à ce livre sont, par ordre alphabétique :

* Yann Adam (France Télécom R&D),
* Pascal Anelli (Laboratoire d'Informatique de Paris 6),
* Alain Baudot (France Télécom R&D),
* Philippe Bereski (Alcatel),
* Jean-Marie Bonnin (GET/ENST Bretagne, Département Réseaux, Sécurité et Multimédia),
* Julien Bournelle (GET/INT, département Logiciels-Réseaux)
* Benoît Brodard (INRIA Sophia Antipolis à l'époque de la rédaction de ce livre),
* Claude Castelluccia (INRIA Rhône-Alpes),
* Isabelle Chrisment (LORIA / Université de Nancy II),
* Luis H. M. K. Costa (Laboratoire d'Informatique de Paris 6),
* Bernard Cousin (IRISA / université de Rennes 1),
* Francis Dupont (GET/ENST Bretagne, Département Réseaux, Sécurité et Multimédia),
* Yann Dupont (CRI Université de Nantes),
* Alain Durand (Comcast),
* Jérôme Durand (Renater),
* Thierry Ernst (Wide project),
* Olivier Festor (LORIA / INRIA Lorraine),
* Jean-Olivier Gerphagnon (BULL),
* Frédéric Gloppe (BULL à l'époque de la rédaction de ce livre),
* Ibrahim Hajjeh (GET/ENST),
* Martin Heusse (IMAG-LSR, Institut d'Informatique et de Mathématiques Appliquées de Grenoble, Laboratoire Logiciels Systèmes Réseaux),
* Mickael Hoerdt (Laboratoire des Sciences de l’Image de l’Informatique et de la Télédétection, Université de Strasbourg - Trondheim/NTNU),
* Christophe Janneteau (Motorola),
* Konstantin Kabassanov (Laboratoire d'Informatique de Paris 6),
* Ghislaine Labouret (HSC, Hervé Schauer Consultants),
* Arthur Lallet (Motorola),
* Maryline Laurent-maknavicius (GET/INT, département Logiciels-Réseaux),
* Yves Legrandgérard (Laboratoire Preuves, Programmes et Systemes - CNRS UMR 7126),
* Aimé Le Rouzic (BULL),
* Vincent Levigneron (AFNIC),
* Emmanuel Lochin (Laboratoire d'Informatique de Paris 6),
* Philippe Lubrano (AFNIC),
* Jérôme Marchand (Artesys International),
* Octavio Medina (GET/ENST Bretagne, Département Réseaux, Sécurité et Multimédia),
* Ana Minaburo (GET/ENST Bretagne, Département Réseaux, Sécurité et Multimédia),
* Simon Muyal (Renater),
* Thomas Noël (Laboratoire des Sciences de l'Image de l'Informatique et de la Télédétection, Université de Strasbourg),
* Alexandru Petrescu (Motorola),
* Bernard Phan Dinh Tuy (CNRS/UREC),
* Yanick Pouffary (HP),
* David Ranch (Juniper Network),
* Jean-Luc Richier (IMAG-LSR, Institut d'Informatique et de Mathématiques Appliquées de Grenoble, Laboratoire Logiciels Systèmes Réseaux),
* Emmanuel Riou (Motorola),
* Ollivier Robert (Eurocontrol),
* Vincent Roca (Laboratoire d'Informatique de Paris 6),
* Jean-Pierre Roch (BULL),
* Imed Romdhani (Napier University, Edinburgh, UK)
* Olivier Salaün
* Luc Saccavini (INRIA),
* Mohsen Souissi (AFNIC),
* Bruno Stévant (GET/ENST Bretagne, Département Réseaux, Sécurité et Multimédia),
* Laurent Toutain (GET/ENST Bretagne, Département Réseaux, Sécurité et Multimédia),
* Jean-Marc Uzé (Juniper Network),
* Rolland Vida (Laboratoire d'Informatique de Paris 6).

Ont participé à cette quatrième édition : Yann Adam, Alain Baudot, Philippe Bereski, Jean-Marie Bonnin, Julien Bournelle, Bernard Cousin, Jérôme Durand, Thierry Ernst, Ibrahim Hajjeh, Martin Heusse, Mickael Hoerdt, Christophe Janneteau, Konstantin Kabassanov, Arthur Lallet, Maryline Laurent-maknavicius, Yves Legrandgérard, Octavio Medina, Ana Minaburo, Simon Muyal, Alexandru Petrescu, Bernard Phan Dinh Tuy, Jean-Luc Richier (éditeur), Emmanuel Riou, Imed Romdhani, Luc Saccavini, Bruno Stévant, Mohsen Souissi, Laurent Toutain (éditeur).

Nos remerciements vont à toutes les personnes qui nous ont aidé à réaliser cet ouvrage :

* Jean-Luc Archimbaud,
* Bob Fink
* Philippe Girault,
* Denis Joiret,
* Mohamed Kassi-Lahlou,
* Daniel Kofman,
* Jean Yves Leboudec
* Philippe Queinnec,
* Rob Romano
* Ahmed Serhouchni,
* Philippe Sonntag,
* Lionel Thual,
* Hervé Troadec,
* Yves et Micheline Troadec.

{{suivi |Accueil|Accueil|Introduction|Introduction}}

Préambule

2007-02-20T16:57:13Z

Bruno Stévant: /* Le Groupe français d'expérimentateurs IPv6 (G6) */

{{suivi |Accueil|Accueil|Introduction|Introduction}}

Dès le début des années 1990, l'évolution du réseau Internet semblait compromise à très court terme, car la conception du protocole IP (Internet Protocol) limitait le nombre d'équipements qui pouvaient s'y connecter. A l'origine, en 1973, ce réseau ne devait servir qu'à relier une centaine de machines. En fait, de nombreuses catégories d'utilisateurs sont très vite venues s'y joindre. Ce furent tout d'abord les scientifiques et les universitaires ; puis, en 1992, le réseau fut ouvert aux activités commerciales avec le succès que l'on sait. L'Internet n'avait pas été prévu pour supporter la croissance exponentielle du nombre d'équipements connectés. Le réseau a menacé d'atteindre la saturation et certains ont prédit son effondrement total en 1994. Comme toute prédiction de ce genre, elle s'est révélée fausse. En effet, dès 1993, des mesures d'urgence avaient été prises. Cela a permis de retarder l'échéance de quelques années. Les ingénieurs et chercheurs travaillant au sein de l'organisme de standardisation de l'Internet ont mis à profit ce délai pour concevoir une nouvelle version du protocole, s'affranchissant des limites imposées par l'actuelle version. Pour éviter toute confusion, la version initiale est désormais appelée IPv4. La version 5 ayant déjà été attribuée à un protocole expérimental, la version issue de ces travaux a été baptisée IPv6.

Ces travaux ont été l'occasion de spécifier les formats et mécanismes nécessaires pour prendre en compte les avancées issues des recherches sur les réseaux menées depuis 25 ans. Elles portent notamment sur l'auto-configuration, la mobilité, la diffusion multi-points, la sécurité (authentification de l'émetteur de l'information et chiffrement des données).

Les travaux principaux concernant IPv6 sont maintenant terminés. De nombreuses implantations sont disponibles aussi bien pour les équipements d'interconnexion que les ordinateurs. Les règles d'attribution des adresses IPv6 sont précisées et les opérateurs commencent à déployer des réseaux de production.

Cet ouvrage fait le point sur les travaux autour de la standardisation d'IPv6, sur ce qui peut être actuellement testé, les problèmes rencontrés au cours du développement, les pistes envisagées pour les résoudre et les sujets qui sont encore du domaine de la recherche. Il s'adresse aussi bien à des étudiants de troisième cycle qu'à des ingénieurs soucieux de préparer l'évolution de leurs réseaux. Cet ouvrage peut servir de référence sur cette nouvelle version du protocole IP en donnant de nombreux exemples tirés de cas réels.

Après une [[Introduction]] expliquant pourquoi le changement de protocole est devenu nécessaire et les principes fondamentaux qui ont été conservés dans IPv6, l'[[Adressage]] présente les différents types d'adresses ([[Lien-local|locale au lien]], [[Unicast Global|globale]], multicast et [[Anycast|anycast]]) et les plans d'adressage test et opérateur.

Le chapitre [[IPv6|Protocoles réseau et transport]] décrit en détail la nouvelle pile de protocoles, le protocole ICMPv6, le protocole MLD utilisé pour la gestion locale des groupes multicast et les modifications à apporter aux protocoles de niveaux supérieurs.

Le chapitre [[Découverte de voisins|Configuration automatique et contrôle]] traite des mécanismes de configuration automatique sans état et des mécanismes de découverte de voisins.

Le chapitre [[Nommage]] s'intéresse aux relations avec les mécanismes de haut niveau nécessaires pour faire la configuration automatique. En particulier les changements apportés au DNS pour prendre en compte les spécifications propres à IPv6.

Le chapitre [[Supports de transmission]] explique le transport d'IPv6 sur différents supports (Ethernet, LLP, PPP, tunnels et UMTS).

Le chapitre [[Installation d'un équipement]] détaille l'insertion des équipements dans un réseau IPv6. Il décrit comment activer et configurer la pile protocolaire des systèmes d'exploitation les plus répandus (Solaris, Windows, AIX, Linux, *BSD,...).

Le chapitre [[Routage]] est consacré aux routage. Il présente les différents protocoles utilisés pour IPv6 (RIPng, OSPF, IS-IS et BGP 4+). Le chapitre [[Configuration des routeurs]] donne des exemples de configuration des routeurs les plus couramment utilisés.

Le chapitre [[Multicast]] traite du multicast IPv6, définit plus en détail le format d'adresses et décrit les protocoles de routages utilisés.

Le chapitre [[Sécurité]] explique les mécanismes de sécurité définis pour IP. Il traite des différentes architectures et des échanges de clés.

Le chapitre [[Mobilité dans IPv6]] traite ensuite des aspects liés à la mobilité.

Le chapitre [[Intégration d'IPv6 et des applications]] s'intéresse aux problèmes de transitions d'IPv4 vers IPv6. Il présente les différents mécanismes ainsi que des scénarios de déploiement.

Enfin, l'interface de programmation est présentée au chapitre [[Programmation d'applications]] (comment utiliser la résolution de nom dans un programme, comment programmer un serveur traitant à la fois des requêtes IPv4 et IPv6, comment programmer des applications réseau comme ping ou comment programmer des applications multicasts).

En annexe, le lecteur trouvera l'[[Historique de la standardisation d’IPv6|historique d'IPv6]] depuis sa genèse, ainsi qu'un rappel du fonctionnement des instances de standardisation de l'Internet (appelé IETF), la [[bibliographie]] détaillée et la structure et l'utilisation des bases whois.

== Le Groupe français d'expérimentateurs IPv6 (G6) ==

L'idée du G6 est née d'une rencontre en novembre 1995 entre Alain Durand de l'IMAG (Institut d'Informatique et de Mathématiques Appliquées de Grenoble) et Bernard Tuy de l'UREC (Unité REseau du CNRS) pour regrouper les actions de différents développeurs et expérimentateurs IPv6 en France. À cette époque, seuls quelques "illuminés" avaient entendu parler d'IPv6 mais, déjà, une implantation réalisée par Francis Dupont de l'INRIA (Institut National de Recherche en Informatique et en Automatique) était disponible.

Le groupe G6 s'est constitué avec des partenaires universitaires et industriels. Autour du noyau originel, se sont retrouvées des personnes venant des Universités de Bordeaux, Lille, Nantes, Paris, Strasbourg, des Écoles Nationales Supérieures de Télécommunications de Bretagne et de Paris, de l'Institut Pasteur, de Bull, d'Alcatel et de 6Wind. Des réunions sont régulièrement organisées dans les différents lieux d'expérimentation.

Outre le partage d'expérience, la participation aux groupes de travail de l'IETF et la participation aux réunions RIPE (Réseaux IP Européens), le groupe s'est donné pour objectif de diffuser largement les connaissances acquises. Cet ouvrage en est la concrétisation majeure et de nombreux séminaires ont été organisés en France et en Europe. Un autre aspect très important des travaux du G6 est la mise en place du réseau G6bone pour relier en IPv6 les différents sites d'expérimentation. Ce réseau est bien sûr partie intégrante du réseau 6bone.

On trouvera plus d'informations sur http://www.g6.asso.fr/.

== L'auteur ==

Au risque de décevoir ses admirateurs, Gisèle Cizault n'existe que dans l'esprit des membres de G6, qui regroupe les utilisateurs français d'IPv6. Les personnes qui ont contribué à ce livre sont, par ordre alphabétique :

* Yann Adam (France Télécom R&D)
* Pascal Anelli (Laboratoire d'Informatique de Paris 6),
* Alain Baudot (France Télécom R&D)
* Philippe Bereski (Alcatel)
* Jean-Marie Bonnin (GET/ENST Bretagne, Département Réseaux et Services Multimédias)
* Julien Bournelle (GET/INT, département Logiciels-Réseaux)
* Benoît Brodard (INRIA Sophia Antipolis à l'époque de la rédaction de ce livre),
* Claude Castelluccia (INRIA Rhône-Alpes),
* Isabelle Chrisment (LORIA / Université de Nancy II),
* Luis H. M. K. Costa (Laboratoire d'Informatique de Paris 6),
* Bernard Cousin (IRISA / université de Rennes 1),
* Francis Dupont (GET/ENST Bretagne, Département Réseaux et Services Multimédias),
* Yann Dupont (CRI Université de Nantes),
* Alain Durand (Comcast),
* Jérôme Durand (Renater)
* Thierry Ernst (Wide project)
* Olivier Festor (LORIA / INRIA Lorraine),
* Jean-Olivier Gerphagnon (BULL)
* Frédéric Gloppe (BULL à l'époque de la rédaction de ce livre),
* Ibrahim Hajjeh (GET/ENST)
* Martin Heusse (IMAG-LSR, Institut d'Informatique et de Mathématiques Appliquées de Grenoble, Laboratoire Logiciels Systèmes Réseaux),
* Mickael Hoerdt (Laboratoire des Sciences de l’Image de l’Informatique et de la Télédétection, Université de Strasbourg - Trondheim/NTNU)
* Christophe Janneteau (Motorola)
* Konstantin Kabassanov (Laboratoire d'Informatique de Paris 6),
* Ghislaine Labouret (HSC, Hervé Schauer Consultants),
* Arthur Lallet (Motorola)
* Maryline Laurent-maknavicius (GET/INT, département Logiciels-Réseaux),
* Yves Legrandgérard (Laboratoire Preuves, Programmes et Systemes - CNRS UMR 7126),
* Aimé Le Rouzic (BULL),
* Vincent Levigneron (AFNIC),
* Emmanuel Lochin (Laboratoire d'Informatique de Paris 6),
* Philippe Lubrano (AFNIC)
* Jérôme Marchand (Artesys International)
* Octavio Medina (GET/ENST Bretagne, Département Réseaux et Services Multimédias),
* Ana Minaburo (GET/ENST Bretagne, Département Réseaux et Services Multimédias),
* Simon Muyal (Renater),
* Thomas Noël (Laboratoire des Sciences de l'Image de l'Informatique et de la Télédétection, Université de Strasbourg),
* Alexandru Petrescu (Motorola)
* Bernard Phan Dinh Tuy (CNRS/UREC),
* Yanick Pouffary (HP)
* David Ranch (Juniper Network)
* Jean-Luc Richier (IMAG-LSR, Institut d'Informatique et de Mathématiques Appliquées de Grenoble, Laboratoire Logiciels Systèmes Réseaux),
* Emmanuel Riou (Motorola)
* Ollivier Robert (Eurocontrol)
* Vincent Roca (Laboratoire d'Informatique de Paris 6),
* Jean-Pierre Roch (BULL),
* Imed Romdhani (Napier University, Edinburgh, UK)
* Olivier Salaün
* Luc Saccavini (INRIA),
* Mohsen Souissi (AFNIC),
* Bruno Stévant (Point6)
* Laurent Toutain (GET/ENST Bretagne, Département Réseaux et Services Multimédias),
* Jean-Marc Uzé (Juniper Network)
* Rolland Vida (Laboratoire d'Informatique de Paris 6).

Ont participé à cette quatrième édition : Yann Adam, Alain Baudot, Philippe Bereski, Jean-Marie Bonnin, Julien Bournelle, Bernard Cousin, Jérôme Durand, Thierry Ernst, Ibrahim Hajjeh, Martin Heusse, Mickael Hoerdt, Christophe Janneteau, Konstantin Kabassanov, Arthur Lallet, Maryline Laurent-maknavicius, Yves Legrandgérard, Octavio Medina, Ana Minaburo, Simon Muyal, Alexandru Petrescu, Bernard Phan Dinh Tuy, Jean-Luc Richier (éditeur), Emmanuel Riou, Imed Romdhani, Luc Saccavini, Bruno Stévant, Mohsen Souissi, Laurent Toutain (éditeur).

Nos remerciements vont à toutes les personnes qui nous ont aidé à réaliser cet ouvrage :

* Jean-Luc Archimbaud,
* Bob Fink
* Philippe Girault,
* Denis Joiret,
* Mohamed Kassi-Lahlou,
* Daniel Kofman,
* Jean Yves Leboudec
* Philippe Queinnec,
* Rob Romano
* Ahmed Serhouchni,
* Philippe Sonntag,
* Lionel Thual,
* Hervé Troadec,
* Yves et Micheline Troadec.

{{suivi |Accueil|Accueil|Introduction|Introduction}}

1er Mars

2007-02-20T13:28:30Z

Bruno Stévant: /* Logistique de la Réunion */

=Réunion commune G6 - Task Force Française IPv6 le 1er mars 2007=

NB: Plus d'information dans les semaines a venir sur cette meme page.

==Introduction==

Vous avez entendu parle d'IPv6 comme étant la nouvelle version du protocole IP (''Internet Protocol'') visant a remplacer la version IPv4 actuelle, vétuste et limitée en nombre d'adresses disponibles, et vous voulez en savoir plus ? L'espace d'adressage de 128 bits d'IPv6 au lieu des 32 bits d'IPv4 permet en effet de connecter une multitude d'ordinateurs, capteurs en tous genres, voitures, téléphones, sans avoir a se partager les adresses ou a avoir recours au NAT (''Network Address Translation'') qui ne permet pas le déploiement des applications pair-a-pair (''peer-to-peer'') et limite le déploiement des fournisseurs d'Accès Internet. Vous voulez cependant en savoir plus sur l'utilisation des adresses IPv6 et vous avez peut-être entendu parle de tout et de son contraire sur les usages des adresses. Cette réunion a pour but de vous expliquer ce pour quoi les adresses IPv6 sont indispensables, et ce pour quoi elles ne sont pas faites.

==Objectif==
Le but de la réunion G6/TFF est de faire le point sur quelques éléments
techniques de base et de montrer les liens entre le G6 et la TFF nouvelle
génération.

Dans le cadre du rôle technique du G6, nous aborderons notamment le
rôle des adresses IPv6, et les mécanismes de transition. Dans la cadre
du rôle complémentaire de la TFF, nous aborderons le cas du déploiement
d'IPv6 a court terme pour certains usages, en particulier a la maison,
pour la santé, et pour les applications multimédia dans l'automobile.

Un certain nombre de tutoriaux sur IPv6 et les enjeux de la nouvelle
version du protocole IP seront exposés.



==Programme Préalable==
*10h00 : Bienvenue
*10h10 : Tutoriel: L'adressage IPv6 qu'est ce que ca changé ?
** CIDR
** Multihoming et Mobilité
*10h40 : Table Ronde sur l'adressage
** Comment avoir des adresses ?
** IPv6 dans l'automobile, vers un nouvel adressage
** Participants:
*** Renault
*** ISP
*** AFNIC
*12h00 : Repas (non organisé)
*14h00 : L'intégration d'IPv6 dans les réseaux
** Les mécanismes de tunnel, comment avoir un préfixe
** Les mécanismes automatiques
*14h30 : Table ronde sur le déploiement
** Comment migrer mes services
** Comment migrer ma téléphonie
** Qu'est ce que ca changé au niveau du DNS ?
*15h30 : Lancement du concours IPv6

==Public Concerné==

Vous êtes responsable de service informatique dans une entreprise et vous devez vous préparer à la venue d'IPv6;

Vous êtes responsable d'une entreprise dans le domaine des STIC

Vous êtes un ISP, vous êtes en charge de dossiers sur les STIC au gouvernement

Vous travaillez dans le domaine des STIC appliqués à la médecine, à la domotique ou à l'automobile

Vous vous intéressez au déploiement d'IPv6

==Logistique de la Réunion==

Date & Heure: <b>1er mars 2007 de 10h a 17h</b>

Lieu: <font color="blue">***ATTENTION CHANGEMENT***</font>: <br>
<b>ENSAM, 151 bd de l'Hôpital à Paris</b>

Réunion gratuite ouverte à tous dans la limite des places disponibles

Déjeuner libre dans les environs.

<b>Inscription préalable nécessaire</b> (par email à <font color="blue">Thierry.Ernst@inria.fr</font>) en indiquant:<br>
- Nom<br>
- Prénom<br>
- Qualité<br>
- Société réprésentée ou participation à titre personnel<br>

Plus d'information dans les semaines à venir sur cette même page.

Talk:Les applications spécifiques

2007-02-20T13:15:50Z

Bruno Stévant:

TODO:
- Mettre à jour Ethereal vers Wireshark

Multicast IPv6 inter-domaine

2006-06-13T19:22:18Z

Bruno Stévant:

{{suivi| Le protocole PIM SSM - Source Specific Multicast| Le protocole PIM SSM - Source Specific Multicast | Déploiement du multicast | Déploiement du multicast}}

L'Internet est comme son nom l'indique une interconnexion de réseaux sous la direction d'entités administratives différentes (AS : ''Autonomous System'') qu'on appelle domaines. Il faut définir des mécanismes qui permettent à ces domaines de dialoguer, tout en préservant leur autonomie. Ces mécanismes sont déjà pleinement déployés pour l'unicast, mais sont encore en plein développement pour ce qui concerne le multicast.

Aujourd'hui, les protocoles multicast interdomaine pour IPv4 sont considérés comme non extensibles comme on le verra dans la section suivante sur [[#ASM|MSDP]]. Ainsi pour IPv6, de nouveaux mécanismes ont été définis, prenant en compte l'existence de deux modèles de diffusion pour les applications : ASM et SSM. Alors que le modèle ASM interdomaine était implémenté par MSDP en IPv4, la solution qui semble privilégiée aujourd'hui est embedded-RP. Pour le modèle SSM, l'utilisation du protocole MLDv2 est indispensable afin d'informer le réseau des sources d'intérêt pour la construction des arbres. Dans cette partie, nous présentons deux solutions qui pourraient être déployées à grande échelle pour le multicast IPv6 : PIM-SM associé à embedded-RP pour l'ASM et PIM-SSM associé à MLDv2 pour SSM.

==ASM==

En IPv4, un domaine PIM correspond à un ensemble de routeurs PIM gérés par une même entité. Tous les routeurs du domaine PIM sont configurés avec le même ensemble de points de rendez-vous qui appartiennent aussi à ce domaine. Pour permettre à des sources et des récepteurs répartis sur différents domaines de participer à une session multicast, un protocole été standardisé et déployé : il s'agit de MSDP (''Multicast Source Discovery Protocol'') [RFC 3618].

Des peerings MSDP sont déployés entre les RP des différents domaines PIM comme indiqué sur la See Peering MSDP. Ils permettent aux RP de s'échanger les informations quant aux sources actives dans les différents domaines. Chaque RP envoie à ses peers MSDP les sources qui émettent et les groupes destinataires.

Des filtres peuvent être appliqués sur les peerings pour permettre les annonces de certaines sources pour certains groupes uniquement.

[[image:CS114.gif]]

Ce protocole classé expérimental ne permet pas une utilisation massive de la technologie multicast puisque les RP doivent s'échanger toutes les sources actives sur l'Internet. De plus, il s'agit d'un protocole compliqué, peu implémenté et difficile à administrer. Aussi, depuis plusieurs années, l'IETF recommande l'utilisation du modèle SSM afin de rendre le modèle plus simple, même si le service rendu est différent avec SSM. Pour toutes ces raisons MSDP n'est pas défini pour IPv6 et il n'existe pas de protocole équivalent.

===Embedded-RP===

En l'absence de MSDP, la construction de l'arbre multicast avec PIM-SM nécessite que tous les routeurs PIM soient configurés avec le même ensemble de RP. Un groupe doit correspondre à un seul RP unique dans tout l'Internet puisque les RP ne peuvent pas s'échanger les informations sur les sources actives en IPv6.

Il est difficile d'imaginer un protocole permettant d'échanger les informations sur les RP existants et les adresses multicast qu'ils gèrent. Un tel protocole ne serait pas meilleur que MSDP.

Une proposition simple a émergé : embarquer l'adresse du RP dans l'adresse multicast (ou embedded-RP). Ceci semble impossible car les deux adresses ont une taille identique (de 128 bits). Cependant, en faisant certaines hypothèses sur l'identifiant d'interface du RP, il est possible de parvenir à cette solution. La méthode de construction d'une adresse [[Adressage multicast#embedded|embedded-RP]] impose quelques changements :

* Modifications sur le protocole PIM SM.
:Embedded-RP [RFC 3618] nécessite une modification de l'algorithme de correspondance entre les adresses multicast et les RP (ou ''group-to-RP mapping''). Pour un paquet à destination d'une adresse dérivée du préfixe <tt>FF70::/12</tt>, l'adresse du RP doit être retrouvée à l'aide des mécanismes décrits [[Adressage multicast#embedded|ici]].
:Embedded-RP doit être supporté sur tous les routeurs de l'arbre partagé, le RP et le DR des sources et des récepteurs. Le support d'embedded-RP sur l'arbre centré sur la source et sur les routeurs entre la source et le RP n'est pas nécessaire puisque ce sont des messages <tt>PIM (S,G) prune/join</tt> qui sont utilisés. Cependant, il est à noter qu'une implémentation sur tous les routeurs PIM SM du réseau simplifie l'utilisation et la gestion de la technologie embedded-RP.
* Impact sur le modèle multicast.
:L'interdomaine multicast en IPv6 apparaît donc très différent de ce qui est réalisé en IPv4. Notamment la notion de domaine PIM disparaît et le terme interdomaine multicast ne correspond plus vraiment. L'Internet IPv6 multicast est un unique domaine PIM dans lesquels sont configurés des multiples points de rendez-vous (cf. figure Le modèle embedded-RP).

[[image:CS115.gif]]

Il est encore difficile à la date de rédaction de ce chapitre de déterminer si ce modèle va être adopté. Si des tests ont montré que la technologie embedded-RP fonctionnait, il reste néanmoins des questions sur les impacts causés par les différences avec le modèle connu et déployé à ce jour pour IPv4.

==Déploiement de SSM sur plusieurs domaines==

Le modèle SSM, implémenté par PIM-SSM constitue un sous-ensemble simplifié du modèle ASM. En effet, il a été défini historiquement pour répondre aux problèmes de l'interdomaine ASM n'ayant pas été résolus en IPv4. Par conséquent, les mécanismes permettant de réaliser l'interdomaine SSM en IPv6 sont très similaires à ceux utilisés en IPv4.

Au niveau du protocole PIM-SSM, il n'y a aucune disposition à prendre pour permettre à ce protocole de fonctionner entre plusieurs domaines. Les messages PIM Join sont acheminés de routeur en routeur entre les DR des récepteurs et les sources spécifiées par les récepteurs. Peu importe donc que les sources soient dans le même domaine que les récepteurs.

Le problème du déploiement du protocole de construction d'arbre multicast PIM-SSM sur plusieurs domaines se situera donc au niveau du routage.

{{suivi| Le protocole PIM SSM - Source Specific Multicast| Le protocole PIM SSM - Source Specific Multicast | Déploiement du multicast | Déploiement du multicast}}

Adressage Global

2006-06-13T14:28:27Z

Bruno Stévant:

{{suivi |Plans d'adressage|Plans d'adressage|Lien-local|Adresses Lien-local}}

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. Une adresse intègre trois niveaux de hiérarchie :

[[image:Fig3-3.png|thumb|right|350px|Figure 3-4 ''Adresse de type plan agrégé'']]

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

La RFC 3513 définit que les préfixes globaux commencent par la séquence binaire <tt>001</tt> : la plage d'adresse pour l'adressage global est donc <tt>2000::/3</tt>. A part le préfixe <tt>3FFE::/16</tt> qui historiquement a servi aux réseaux expérimentaux du [[La standardisation d'IPv6#6bone|6bone]] et le préfixe <tt>2002::/16</tt> servant au mécanisme de transition [[Déploiement IPv6 des fournisseurs d'accès (ISP)#6to4|6to4]], les autres blocs de 16 bits sont alloués par l'IANA aux registres régionaux. Une version à jour des allocations est disponible sur le site http://www.iana.org/assignments/ipv6-unicast-address-assignments. On retrouve les principes de délegation d'IPv4 sur son premier octet.

Initialement, l'IANA a commencé a affecté des préfixes dans la plage <tt>2001::/16</tt>, les opérateurs se voyait attribuer des préfixes de longueur 32. Ainsi l'operateur du réseau national de la recherche française Renater a reçu le préfixe <tt>2001:660::/32</tt>.

>'''whois -h whois.ripe.net 2001:660::/32'''
% This is the RIPE Whois query server #1.
% The objects are in RPSL format.
%
% Note: the default output of the RIPE Whois server
% is changed. Your tools may need to be adjusted. See
% http://www.ripe.net/db/news/abuse-proposal-20050331.html
% for more details.
%
% Rights restricted by copyright.
% See http://www.ripe.net/db/copyright.html

% Note: This output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '2001:0660::/32'

inet6num: 2001:0660::/32
netname: FR-RENATER-20000321
descr: Renater Sub-TLA block
descr: Reseau National de telecommunications pour la
descr: Technologie l'Enseignement et la Recherche
descr: National telecommunications network
descr: for Technology, Education and Research
country: FR

[...]

% Information related to '2001:0660::/32AS2200'

route6: 2001:0660::/32
descr: RENATER
origin: AS2200
mnt-by: RENATER-MNT
source: RIPE # Filtered

Mais d'autres préfixes ont été libérés pour les opérateurs "grand public". 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. Il semble que cela pourrait remettre en cause l'attribution de préfixes de longueur 48 pour tous les utilisateurs au profit de préfixes plus long. La tendance pour ce type d'opérateur est de leur attribuer des préfixes de longueurs 19.

>'''whois -h whois.ripe.net 2a01:c000::/19'''
% This is the RIPE Whois query server #1.
% The objects are in RPSL format.
%
% Note: the default output of the RIPE Whois server
% is changed. Your tools may need to be adjusted. See
% http://www.ripe.net/db/news/abuse-proposal-20050331.html
% for more details.
%
% Rights restricted by copyright.
% See http://www.ripe.net/db/copyright.html

% Note: This output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '2a01:c000::/19'

inet6num: 2a01:c000::/19
netname: FR-TELECOM-20051230
descr: France Telecom
country: FR

{{suivi |Plans d'adressage|Plans d'adressage|Lien-local|Adresses Lien-local}}

Configuration automatique

2006-06-08T09:38:01Z

Bruno Stévant: /* Création de l'adresse lien-local */

{{suivi|Exemples de découverte de voisins|Exemples de découverte de voisins|Exemples de configuration sans état|Exemples de configuration sans état}}
Traditionnellement, la configuration d'une interface réseau d'une machine demande une configuration manuelle. C'est un travail souvent long et fastidieux. Avec IPv6, cette configuration est automatisée, introduisant par là-même des caractéristiques de fonctionnement immédiat (''plug and play'') à l'interface réseau. La configuration automatique signifie qu'une machine obtient toutes les informations nécessaires à sa connexion à un réseau local IP sans aucune intervention humaine. Dans le cas idéal, un utilisateur quelconque déballe son nouvel ordinateur, le connecte au réseau local et le voit fonctionner sans devoir y introduire des informations de "spécialiste". Nous avons vu [[Exemples de découverte de voisins#defaut|comment les routes étaient installées]] dans la table de routage des machines. Nous allons maintenant étudier l'autre aspect de l'autoconfiguration de IPv6 qui est l'autoconfiguration d'adresses. Celle-ci a pour objectif :

* l'acquisition d'une adresse quand une machine est attachée à un réseau pour la première fois ;
* l'obtention de la nouvelle adresse suite à la renumérotation des machines du site après un changement d'opérateur. L'opération de re-numérotage revient concrètement à changer la partie haute de l'adresse. L'autoconfiguration d'adresses va servir de vecteur dans l'attribution du nouveau préfixe.

Le processus d'autoconfiguration d'adresse d'IPv6 comprend la création d'une adresse lien-local, la vérification de son unicité, la détermination de adresses unicasts globales. IPv6 spécifie deux méthodes d'autoconfiguration pour l'adresse unicast globale :

* l'autoconfiguration sans état (stateless autoconfiguration, RFC 2462) ; elle est utilisée quand la gestion administrative des adresses attribuées n'est pas nécessaire au sein d'un site. Ces mécanismes sont décrit dans la suite de ce chapitre.
* l'autoconfiguration avec état (stateful autoconfiguration) ; elle est retenue lorsqu'un site demande un contrôle strict de l'attribution des adresses. Ce mécanisme est décrit Autoconfiguration avec état [[Configuration avec état :DHCPv6|DHCPv6]].

Le rôle du routeur est important dans l'autoconfiguration. Il dicte à la machine, par des bits (cf. [[Découverte de voisins#RA|Annonce du routeur]]) de l'en-tête du message d'annonce de routeurs, la méthode à retenir et fournit éventuellement les informations nécessaires à sa configuration. Le bit <tt>M</tt> (''Managed address configuration'') mis à 1 indique que l'équipement ne doit pas construire lui-même l'adresse à partir de son identifiant d'interface et des préfixes reçus, mais doit explicitement demander son adresse auprès d'une application d'un serveur d'adresse. Le bit <tt>O</tt> (''Other stateful configuration'') indique que l'équipement doit interroger le serveur de configuration pour obtenir des paramètres autre que l'adresse. L'algorithme de la procédure d'autoconfiguration d'adresse se décompose de la manière suivante :

* La toute première étape consiste à créer l'adresse lien-local.
* Une fois l'unicité de cette adresse vérifiée, la machine est en mesure de communiquer avec les autres machines du lien.
* La machine doit chercher à acquérir un message d'annonce du routeur pour déterminer la méthode d'obtention de l'adresse unicast globale.
* S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message d'annonce de routeurs, à savoir :
** l'autoconfiguration sans état,
** l'autoconfiguration avec état.
* En l'absence de routeur sur le lien, la machine doit essayer d'acquérir l'adresse unicast globale par la méthode d'autoconfiguration avec état. Si la tentative échoue, c'est terminé. Les communications se feront uniquement sur le lien avec l'adresse lien-local. La machine n'a pas une adresse avec une portée qui l'autorise à communiquer avec des machines autres que celles du lien.

==<div id="DAD"> Détection d'adresse dupliquée </div>==

Pour vérifier l'unicité des adresses unicast, les machines doivent exécuter un algorithme de Détection d'Adresse Dupliquée (DAD) avant de les utiliser. L'algorithme utilise les messages ICMPv6 [[Découverte de voisins#NS|sollicitation d'un voisin]] et [[Découverte de voisins#NA|annonce d'un voisin]]. Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'autoconfiguration s'arrête et une intervention humaine devient obligatoire. Une adresse est qualifiée de "provisoire" pendant l'exécution de l'algorithme DAD et ce jusqu'à la confirmation de son unicité. Une adresse provisoire est assignée à une interface uniquement pour recevoir les messages de sollicitation et d'annonce d'un voisin. Les autres messages reçus sont ignorés. L'algorithme DAD consiste à envoyer un message sollicitation d'un voisin avec dans le champ adresse de la cible l'adresse provisoire. Afin de distinguer, l'algorithme DAD de celui de découverte des voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de source l'adresse indéterminée. Trois cas se présentent :

* Un message annonce d'un voisin est reçu : l'adresse provisoire est utilisée comme adresse valide par une autre machine. L'adresse provisoire n'est pas unique et ne peut être retenue.
* Un message sollicitation d'un voisin est reçu dans le cadre d'une procédure DAD; l'adresse provisoire est également une adresse provisoire pour une autre machine. L'adresse provisoire ne peut être utilisée par aucune des machines.
* Rien n'est reçu au bout d'une seconde (valeur par défaut) : l'adresse provisoire est unique, elle passe de l'état de provisoire à celle de valide et elle est assignée à l'interface.

A noter que cet algorithme n'offre pas une fiabilité absolue, notamment lorsque le lien est coupé.

==Création de l'adresse lien-local==

À l'initialisation de son interface, la machine construit un identifiant pour l'interface qui doit être unique au lien. Cet identifiant utilise l'adresse [[Identifiant_d'interface#EUI-64|EUI-64]]. Le principe de base de la création d'adresse IPv6 est de marier un préfixe avec l'identifiant. L'adresse lien-local est créée en prenant le préfixe lien-local (<tt>FE80::/64</tt>) qui est fixé. L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire car la machine doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée. Si la machine détermine l'adresse lien-local n'est pas unique, l'autoconfiguration s'arrête et une intervention manuelle est nécessaire.

Une fois que l'assurance sur l'unicité de l'adresse lien-local est obtenue, l'adresse provisoire devient une adresse valide pour l'interface. La première phase de l'autoconfiguration est achevée.

== Autoconfiguration sans état ==

L'autoconfiguration sans état (RFC 2462) ne demande aucune configuration manuelle des machines, une configuration minimum pour les routeurs et aucun serveur supplémentaire. Elle se sert du protocole ICMPv6 et peut fonctionner sans la présence de routeurs. Elle nécessite cependant un sous-réseau à diffusion. Cette méthode ne s'applique que pour les machines et ne peut être retenue pour la configuration des routeurs. Le principe de base de l'autoconfiguration sans état est qu'une machine génère son adresse IPv6 à partir d'informations locales et d'informations fournies par un routeur. Le routeur fournit à la machine les informations sur le sous-réseau associé au lien, il donne le préfixe.

Comme pour la création de l'adresse lien-local, l'adresse unicast globale est obtenue en concaténant le préfixe avec l'identifiant de l'interface. Le préfixe provient du message d'annonce de routeurs et plus précisément de l'option «information sur le préfixe». Bien qu'il faille vérifier l'unicité de toutes les adresses unicast, dans le cas d'une adresse unicast obtenue par autoconfiguration sans état cela n'est pas obligatoire. En effet, l'unicité de l'identifiant de l'interface a déjà été contrôlé dans l'étape de création de l'adresse lien-local. L'identifiant étant le même, il n'y a plus aucune ambiguïté sur son unicité. L'adresse unicast globale constituée est aussi unique que celle lien-local.

La re-numérotation des machines d'un lien s'effectue au moyen des routeurs qui passent les adresses utilisées dans un état déprécié et annoncent en même temps le nouveau préfixe. Les machines pourront recréer une adresse préférée.
{{suivi|Exemples de découverte de voisins|Exemples de découverte de voisins|Exemples de configuration sans état|Exemples de configuration sans état}}

Exemples de découverte de voisins

2006-06-08T09:34:29Z

Bruno Stévant: /* <div id="defaut">Configuration de la route par défaut</div> */

{{suivi|Découverte de voisins|Découverte de voisins|Configuration automatique|Configuration automatique}}
==Ping et résolution d'adresses==

Les paquets suivants ont été obtenus lors d'un ping entre deux stations IPv6 situées sur le même réseau physique de type Ethernet.

uma# '''ping6 ganesha'''
trying to get source for ganesha
source should be 3ffe:302:12:3:a00:20ff:fe0a:aa6d
PING ganesha (3ffe:302:12:3::3): 56 data bytes
64 bytes from 3ffe:302:12:3::3: icmp6_seq=0 ttl=255 time=5.121 ms

Avant de pouvoir émettre un paquet ICMPv6 de demande d'écho, l'émetteur a besoin de connaître l'adresse physique de l'équipement destinataire. Il utilise le protocole de découverte des voisins et émet une trame de sollicitation d'un voisin.

Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:0:0:3 Type : 0x86dd
IPv6
Version : 6 Classe : 0xf0 Label : 000000
Longueur : 32 octets (0x0020) Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 255 (0xff)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : ff02::1:ff00:3 (multicast sollicité associé à 3ffe:302:12:3::3)
ICMPv6
Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x4d7f
Cible : 3ffe:302:12:3::3 (ganesha)
Option :
Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d

0000: ''6<font color="blue">f 0</font>0 00 00 <font color="blue">00 20</font> 3a <font color="blue">ff</font> 3f fe 03 02 00 12 00 03''
0010: ''0a 00 20 ff fe 0a aa 6d <font color="blue">ff 02 00 00 00 00 00 00</font>''
0020: ''<font color="blue">00 00 00 01 ff 00 00 03</font>|87 <font color="blue">00</font> 4d 7f <font color="blue">00 00 00 00</font>''
0030: ''3f fe 03 02 00 12 00 03 00 00 00 00 00 00 00 03|''
0040: ''01 <font color="blue">01</font> 08 00 20 0a aa 6d''

Dans l'en-tête IPv6, l'adresse de la source est l'adresse globale de l'interface d'émission. On aurait pu penser que l'émetteur utilisait l'adresse locale au lien comme adresse de la source. L'utilisation de l'adresse source globale, comme on le verra par la suite, permet au destinataire de remplir directement sa table de correspondance entre adresse IPv6 et adresse physique, puisque ce dernier trouvera dans la suite du datagramme l'adresse physique de l'émetteur.

L'adresse de destination est l'adresse de [[Réseaux à diffusion#sol|multicast sollicité]] associée à l'adresse recherchée et l'adresse Ethernet de destination est l'adresse associée (cf. [[Supports de transmission]] RFC 2464).

L'en-tête ICMPv6 contient dans le champ cible l'adresse IPv6 de la machine dont l'adresse physique est recherchée. On peut remarquer que les trois derniers octets correspondent au groupe de multicast de l'en-tête IPv6.

Le champ option contient l'adresse physique de l'émetteur de la requête.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd
IPv6
Version : 6 Classe : 0xf0 Label : 000000
Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 255 (0xff)
Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)
Desti. : 3ffe:302:12:3:0a00:20ff:fe0a:aa6d (uma)
ICMPv6
Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0xd7fb
Bits (0x7) R = 1, S = 1, O = 1
Cible : 3ffe:302:12:3::3 (ganesha)
Option :
Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34

La machine <tt>ganesha</tt>, qui écoute sur tous les groupes [[Réseaux à diffusion#sol|multicast sollicité]] associés à ses adresses, reçoit le message de sollicitation de voisin, reconnaît dans la cible une de ses adresses IPv6, et répond. L'adresse source utilisée est locale au lien. Le bit <tt>R</tt> indique que l'équipement qui répond a une fonction de routeur. Le bit <tt>S</tt> indique que ce message est une réponse à une demande explicite (le message précédent). Le bit <tt>O</tt> indique que cette réponse doit remplacer toute valeur connue précédemment. Le champ cible rappelle l'adresse IPv6. Le champ option donne l'adresse physique recherchée.

Ethernet Src : 8:0:20:a:aa:6d Dst : 1a:0:20:c:7a:34 Type : 0x86dd
IPv6
Version : 6 Classe : 0x00 Label : 000000
Longueur : 64 octets (0x0040) Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 255 (0xff)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : 3ffe:302:12:3::3 (ganesha)
ICMPv6
Type : 128 (0x80, Demande d'écho) Code : 0 Checksum : 0x0f20
Identificateur : 0x00c0 Numéro de séquence : 0x0000
Données : Date : 0x3468c4c7.000631c7 Remplissage ...

L'émetteur envoie un message ICMPv6 [[ICMPv6#echo|Demande d'écho]].

Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd
IPv6
Version : 6 Classe : 0x00 Label : 000000
Longueur : 64 octets (0x0040) Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 255 (0xff)
Source : 3ffe:302:12:3::3 (ganesha)
Desti. : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
ICMPv6
Type : 129 (0x81, Réponse d'écho) Code : 0 Checksum : 0x0e20
Identificateur : 0x00c0 Numéro de séquence : 0x0000
Données : Celles de la demande

Le destinataire acquitte en retournant un message ICMPv6 [[ICMPv6#echo|Réponse d'écho]]. Il n'est pas nécessaire de relancer une phase de résolution d'adresse puisque la précédente a permis de remplir le cache.

Les échanges ICMP [[ICMPv6#echo|Demande d'écho]] et [[ICMPv6#echo|Réponse d'écho]] continuent ensuite toutes les secondes. Si les échanges continuent assez longtemps, les deux machines vérifieront périodiquement que le correspondant est toujours correct (il a pu tomber en panne ou être remplacé avec changement d'adresse Ethernet) en utilisant le protocole [[Découverte de voisins#NUD|NUD]]. Aussi de temps en temps, chaque machine va émettre une trame [[Découverte de voisins#NS|sollicitation d'un voisin]]. Une réponse ([[Découverte de voisins#NA|annonce de voisin]] avec le bit <tt>S</tt>) montre que le correspondant est toujours valide.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd
IPv6
Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)
Desti. : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
ICMPv6
Type : 135 (0x87, Sollicitation de voisin) Code : 0
Cible : 3f fe 03 02 00 12 00 03 0a 00 20 ff fe 0a aa 6d
Option : aucune

On remarque que le message de sollicitation est directement adressé au destinataire, avec l'adresse qui est enregistrée dans les tables de correspondance. Si une réponse n'arrive pas, la machine émettrice effacera l'entrée de son cache «Résolution de voisin». Tout trafic ultérieur reprendra l'enquête de résolution au début, avec diffusion vers l'adresse [[Réseaux à diffusion#sol|multicast sollicité]]-- au cas où l'adresse Ethernet aurait changée.

== <div id="defaut">Configuration de la route par défaut</div> ==

[[image:Fig5-10.png|thumb|right|400px|Figure 5-10 ''Annonces du routeur'']]

En IPv6 seuls les routeurs utilisent des protocoles de routage pour définir leurs tables de routage. Le routage des autres machines repose sur la notion de route par défaut. Comme avec IPv4, l'envoi de messages de redirection est utilisé pour installer de meilleures routes. Périodiquement les routeurs envoient des [[Découverte de voisins#RA|Annonces du routeur]] qui permettent aux machines sur le câble de choisir un routeur par défaut, et aussi de calculer leur adresse (dans le mode d'autoconfiguration sans état stateless).

Un même câble Ethernet relie 3 machines (cf. figure Annonces de routeurs) :

* deux routeurs <tt>ganesha</tt> et <tt>tuna</tt>,
* et une autre machine <tt>uma</tt>.

Les routeurs émettent périodiquement sur le réseau des messages d'annonce.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 33:33:0:0:0:1 Type : 0x86dd
IPv6
Version : 6 Classe : 0xf Label : 000000
Longueur : 56 octets (0x0038) Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 255 (0xff)
Source : fe80::1800:200c:7a34 (ganesha, lien-local)
Desti. : ff02::1 (multicast, tous les n??uds du lien)
ICMPv6
Type : 134 (0x86, Annonce de routeur) Code : 0 Checksum : 0x773c
Nombre de sauts : 0 (non précisé) Gestion d'adresse : 0 (Pas de DHCP)
Validité : 6000 secondes (0x1770) Timers : 0, 0 (non précisés)
Options :
Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34
Type : 3 (Information sur le préfixe) Lg : 32 octets (0x04)
Drapeaux : L=1, A=1 Durée de validité : -1, -1 (infinie)
Préfixe : 3ffe:302:12:3::/64

0000: 6f 00 00 00 00 38 3a ff fe 80 00 00 00 00 00 00
0010: 18 00 20 ff fe 0c 7a 34 ff 02 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 01|86 00 77 3c 00 00 17 70
0030: 00 00 00 00 00 00 00 00|01 01 1a 00 20 0c 7a 34|
0040: 03 04 40 c0 ff ff ff ff ff ff ff ff 00 00 00 00
0050: 3f fe 03 02 00 12 00 03 00 00 00 00 00 00 00 00

Ce message est envoyé par le routeur <tt>ganesha</tt> (l'adresse source est l'adresse locale, commençant par <tt>fe80</tt>), à destination de tous les noeuds sur le câble Ethernet (adresse de destination IPv6 «Tous les noeuds sur le lien» <tt>ff02::1</tt> et l'adresse de destination physique est l'adresse MAC de multicast associée). Les informations donnent la durée de vie de cette annonce, des paramètres de configuration pour les noeuds, dont le type de construction d'adresse : mode d'autoconfiguration [[''stateless'']] en créant une adresse permanente à partir du préfixe <tt>3ffe:302:12:3::/64</tt>.

La table de routage d'<tt>uma</tt> après réception de ce message contient :

uma# '''netstat -nrf inet6'''
Routing tables IPv6:
Destination Gateway Flags Refs Use Mtu Interf
default fe80::1800:20ff:fe0c:7a34 UGS 0 17 1500 le0
fe80::1800:20ff:fe0c:7a34 1a:0:20:c:7a:34 U HDL 1 2 1500 le0
.....

La ligne avec le drapeau <tt>L</tt> correspond à une machine directement accessible, le champ ''Gateway'' contient l'adresse IEEE 802. Il s'agit des informations contenues dans la table de correspondance construite par le protocole de découverte des voisins.

Le routeur <tt>tuna</tt> avait lui aussi émis des annonces de routeur. On pourrait donc aussi enregistrer une route par défaut via <tt>tuna</tt> ; mais le système ne conserve qu'une route par défaut, et la route possible par <tt>tuna</tt> est ignorée. De même, il n'y a pas de ligne de correspondance adresse IPv6-adresse Ethernet pour <tt>tuna</tt> car cette adresse n'a pas été utilisée comme destination.

==<div id="indredir">Indication de redirection</div>==

[[image:Fig5-11.png|thumb|right|400px|Figure 5-11 ''Routage par défaut non optimal'']]

La configuration donnée figure Routage par défaut non optimal après la configuration des routes par défaut conduit aux tables de routage suivantes : la route par défaut d'<tt>uma</tt> pointe sur <tt>ganesha</tt>, et la route vers la machine externe <tt>3ffe:200:1:3::1</tt> sur <tt>ganesha</tt> pointe sur <tt>tuna</tt>.

La machine <tt>uma</tt> envoie un ping à la machine externe <tt>3ffe:200:1:3::1</tt> en utilisant la route par défaut, non optimale.

uma# '''ping6 3ffe:200:1:3::1'''
trying to get source for 3ffe:200:1:3::1
source should be 3ffe:302:12:3:a00:20ff:fe0a:aa6d
PING 3ffe:200:1:3::1: 56 data bytes
64 bytes from 3ffe:200:1:3::1: icmp6_seq=0 ttl=253 time=79.689 ms
.....

En observant le réseau, on trouve le trafic suivant.

Ethernet Src : 8:0:20:a:aa:6d Dst : 1a:0:20:c:7a:34 Type : 86dd
IPv6
Version : 6 Classe : 0x00 Label : 000000
Longueur : 64 octets (0x0040) Protocole : 58 (0x3a, ICMPv6)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : 3ffe:200:1:3::1 (gw-uni)
ICMPv6
Type : 128 (0x80, Demande d'écho) Code : 0 Checksum : 0xd775
Identificateur : 0x00d6 Numéro de séquence : 0x0000
Données : Date : 0x3469a2a4.000d8c8b Remplissage ...

Le message ICMPv6 d'écho est transmis vers l'adresse Ethernet de <tt>ganesha</tt>, routeur par défaut d'<tt>uma</tt>.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 0:0:c0:86:e2:e9 Type : 86dd
IPv6
Version : 6 Classe : 0x00 Label : 000000
Longueur : 64 octets (0x0040) Protocole : (0x3a, ICMPv6)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : 3ffe:200:1:3::1 (gw-uni)
ICMPv6
Type : 128 (0x80, Demande d'écho) Code : 0 Checksum : 0xd775
Identificateur : 0x00d6 Numéro de séquence : 0x0000
Données : Date : 0x3469a2a4.000d8c8b Remplissage ...

<tt>ganesha</tt> retransmet le paquet IPv6 non modifié vers l'adresse Ethernet de <tt>tuna</tt>, qui est le premier relais sur la route vers la destination finale.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 86dd
IPv6
Version : 6 Classe : 0xf0 Label : 000000
Longueur : 160 octets (0x00a0) Protocole : (0x3a, ICMPv6)
Source : fe80::1800:20ff:fe0c:7a34 (ganesha,lien-local)
Desti. : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
ICMPv6
Type : 137 (0x89, Redirection) Code : 0 Checksum : 0x869d
Meilleur routeur : fe80::200:c0ff:fe86:e2e9 (tuna, lien-local)
Destination : 3ffe:200:1:3::1 (gw-uni)
Options :
Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 00-00-c0-86-e2-e9
Type : 4 (Paquet ayant causé le message) Longueur : 112 octets (0x0e)
Début du paquet IPv6 ayant causé le message

<tt>ganesha</tt> constate que le paquet d'écho a été réémis sur l'interface qui l'avait reçu, et génère donc un message de redirection vers <tt>uma</tt> pour lui indiquer qu'une meilleure route vers <tt>3ffe:200:1:3::1</tt> utilise le routeur <tt>fe80::200:c0ff:fe86:e2e9</tt>.

En IPv6 l'adresse Ethernet du routeur est fournie, ce qui évite une résolution supplémentaire.

Ethernet Src : 8:0:20:a:aa:6d Dst : 0:0:c0:86:e2:e9 Type : 86dd
IPv6
Version : 6 Classe : 0x00 Label : 000000
Longueur : 64 octets (0x0040) Protocole : (0x3a, ICMPv6)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : 3ffe:200:1:3::1 (gw-uni)
ICMPv6
Type : 128 (0x80, Demande d'écho) Code : 0 Checksum : 0xf51f
Identificateur : 0x00d6 Numéro de séquence : 0x0001
Données : Date : 0x3469a2a6.000d6edd Remplissage ...

Le paquet de demande d'écho suivant est envoyé directement vers l'adresse Ethernet de <tt>tuna</tt>.

La table de routage d'<tt>uma</tt> est maintenant :

uma# '''netstat -nrf inet6'''
Routing tables IPv6:
Destination Gateway Flags Refs Use Mtu Interf
default fe80::1800:20ff:fe0c:7a34 UGS 0 17 1500 le0
3ffe:200:1:3::1 fe80::200:c0ff:fe86:e2e9 UGHD 0 2 1500 le0
fe80::200:c0ff:fe86:e2e9 0:0:c0:86:e2:e9 UHDL 1 0 1500 le0
fe80::1800:20ff:fe0c:7a34 1a:0:20:c:7a:34 UHDL 1 2 1500 le0
.....

==Indication de redirection externe==

[[image:Fig5-11.png|thumb|right|400px|Figure 5-11 ''Routage par défaut non optimal'']]

En IPv4, le mécanisme de redirection n'est prévu que pour les machines auxquelles on accède par l'intermédiaire d'un routeur ; la machine émettrice doit connaître les adresses IPv4 directement accessibles (le numéro de réseau correspondant au lien physique), un «ICMP Redirect» ne fonctionne pas pour celles-ci.

En IPv6, il n'est plus nécessaire de connaître tous les préfixes IPv6 correspondant au lien physique, une machine peut se contenter de connaître son adresse, un routeur par défaut, et envoyer tout le trafic inconnu sur ce routeur. Le mécanisme de redirection permettra de rediriger le trafic vers la destination la meilleure dans tous les cas.

Dans l'exemple correspondant à la figure Routage par défaut non optimal, supposons que <tt>guma</tt> a pour adresse globale sur l'interface partagée avec <tt>uma</tt> <tt>3ffe:302:12:4::4</tt>, et que <tt>uma</tt> n'a pas pris en compte dans ses tables de routage que le câble contient des machines appartenant à un préfixe <tt>3ffe:302:12:4::4/64</tt>. Ceci peut être dû au fait que <tt>uma</tt> n'analyse pas tous les préfixes, ou parce que le préfixe n'est pas annoncé sur le câble. Ce cas de figure est courant si le lien reliant <tt>uma</tt> et <tt>guma</tt> est un réseau ATM.

La machine <tt>uma</tt> veut accéder à <tt>guma</tt> :

uma# '''ping6 3ffe:302:12:4::4'''
trying to get source for 3ffe:302:12:4::4
source should be 3ffe:302:12:3:a00:20ff:fe0a:aa6d
PING 3ffe:302:12:4::4: 56 data bytes
64 bytes from 3ffe:302:12:4::4: icmp6_seq=0 ttl=255 time=7.267 ms
.....

Ethernet Src : 8:0:20:a:aa:6d Dst : 1a:0:20:c:7a:34 Type : 86dd
IPv6
Version : 6 Classe : 0x00 Label : 000000
Longueur : 64 octets (0x0040) Protocole : (0x3a, ICMPv6)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : 3ffe:302:12:4::4 (guma)
ICMPv6
Type : 128 (0x80, Demande d'écho) Code : 0 Checksum : 0x43cc
Identificateur : 0x00fd Numéro de séquence : 0x0000
Données : Date : 0x337b4e95.0002725d Remplissage ...

Puisque <tt>uma</tt> ne sait pas que <tt>guma</tt> est directement accessible, le message ICMP d'écho est transmis vers l'adresse Ethernet de <tt>ganesha</tt>, routeur par défaut d'<tt>uma</tt>.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 0:0:c0:89:e2:e6 Type : 86dd
IPv6
Version : 6 Classe : 0x00 Label : 000000
Longueur : 64 octets (0x0040) Protocole : (0x3a, ICMPv6)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : 3ffe:302:12:4::4 (guma)
ICMPv6
Type : 128 (0x80, Demande d'écho) Code : 0 Checksum : 0x43cc
Identificateur : 0x00fd Numéro de séquence : 0x0000
Données : Date : 0x337b4e95.0002725d Remplissage ...

<tt>ganesha</tt> retransmet le paquet non modifié vers <tt>guma</tt>.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 86dd
IPv6
Version : 6 Classe : 0xf0 Label : 000000
Longueur : 160 octets (0x00a0) Protocole : (0x3a, ICMPv6)
Source : fe80::1800:20ff:fe0c:7a34
Desti. : 3ffe:302:12:3:a00:20ff:fe0a:aa6d
ICMPv6
Type : 137 (0x89, Redirection) Code : 0 Checksum : 0xfe45
Meilleur routeur : 3ffe:302:12:4::4 (guma)
Destination : 3ffe:302:12:4::4 (guma)
Options :
Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 00-00-c0-89-e2-e6
Type : 4 (Paquet ayant causé le message) Longueur : 112 octets (0x0e)
Début du paquet IPv6 ayant causé le message

De plus <tt>ganesha</tt> envoie à <tt>uma</tt> un message de redirection. C'est une redirection vers une machine sur le lien physique, ce qui est indiqué par le fait que les champs «Meilleur routeur» et «Destination» sont égaux (le premier relais est la destination finale).

Ethernet Src : 0:0:c0:89:e2:e6 Dst : 8:0:20:a:aa:6d Type : 86dd
IPv6
Version : 6 Classe : 0xf0 Label : 000000
Longueur : 64 octets (0x0040) Protocole : (0x3a, ICMPv6)
Source : 3ffe:302:12:4::4
Desti. : 3ffe:302:12:3:a00:20ff:fe0a:aa6d
ICMPv6
Type : 129 (0x81, Réponse d'écho) Code : 0 Checksum : 0x42cc
Identificateur : 0x00fd Numéro de séquence : 0x0001
Données : Celles de la demande

La réponse de <tt>guma</tt> parvient à <tt>uma</tt> (les messages de sollicitation de voisin échangés ne sont pas montrés dans cet exemple).

Ethernet Src : 8:0:20:a:aa:6d Dst : 0:0:c0:89:e2:e6 Type : 86dd
IPv6
Version : 6 Classe : 0xf0 Label : 000000
Longueur : 64 octets (0x0040) Protocole : (0x3a, ICMPv6)
Source : 3ffe:302:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : 3ffe:302:12:4::4 (guma)
ICMPv6
Type : 128 (0x80, Demande d'écho) Code : 0 Checksum : 0x43be
Identificateur : 0x00fd Numéro de séquence : 0x0001
Données : Date : 0x337b4e96.00027269 Remplissage ...

Les demandes d'écho suivantes sont adressées directement à l'adresse Ethernet de <tt>guma</tt>.
La table de routage d'<tt>uma</tt> est maintenant :

uma# netstat -nrf inet6
Routing tables IPv6:
Destination Gateway Flags Refs Use Mtu Interf
default fe80::1800:20ff:fe0c:7a34 UGS 0 17 1500 le0
3ffe:302:12:4::4 0:0:c0:89:e2:e6 UHDL 0 3 1500 le0
3ffe:200:1:3::1 fe80::200:c0ff:fe86:e2e9 UGHD 0 2 1500 le0
fe80::200:c0ff:fe86:e2e9 0:0:c0:86:e2:e9 UHDL 1 0 1500 le0
fe80::1800:20ff:fe0c:7a34 1a:0:20:c:7a:34 UHDL 1 2 1500 le0
.....

On voit qu'il y a maintenant une ligne avec le drapeau <tt>L</tt> pour la machine <tt>guma</tt>. Le drapeau <tt>L</tt> et l'absence de drapeau <tt>G</tt> indiquent une machine directement accessible, sans routeur intermédiaire.

{{suivi|Découverte de voisins|Découverte de voisins|Configuration automatique|Configuration automatique}}

Découverte de voisins

2006-06-08T09:32:00Z

Bruno Stévant: /* <div id="IR">Indication de redirection</div> */

{{suivi|Protocoles de Niveau 4|Protocoles de Niveau 4|Exemples de découverte de voisins|Exemples de découverte de voisins}}

__TOC__

Le protocole de découverte des voisins neighbor discovery permet à un équipement de s'intégrer dans l'environnement local, c'est-à-dire le lien sur lequel sont physiquement transmis les paquets IPv6. Il permet de dialoguer avec les équipements connectés au même support (stations et routeurs). Il ne s'agit pas pour un équipement de connaître exactement la liste de tous les autres équipements connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.

Le protocole utilise cinq types de messages ICMPv6 (voir [[Modèle:Tableau ICMPv6|Valeurs des champs type et code d'ICMPv6]]). Le champ nombre de sauts de l'en-tête IPv6 contient la valeur 255 -- il peut sembler paradoxal d'utiliser une valeur aussi grande pour des datagrammes qui ne doivent pas être routés hors du lien physique ; en fait si un équipement reçoit un datagramme avec une valeur plus petite, cela signifie que l'information provient d'un autre réseau et que le datagramme doit être rejeté.

Le protocole réalise les différentes fonctions :

* Résolution d'adresses. Le principe est très proche du protocole ARP que l'on trouve avec IPv4. La principale différence vient de l'emploi de messages standards ICMPv6 à la place de la définition d'un autre protocole de niveau 3. Cela confère une plus grande souplesse d'utilisation en particulier sur les réseaux qui ne supportent pas la diffusion. Comme pour IPv4, ce protocole construit des tables de mise en correspondance entre les adresses IPv6 et physiques.
* <div id="NUD">Détection d'inaccessibilité des voisins ou NUD (''Neighbor Unreachability Detection''). Cette fonction n'existe pas en IPv4. Elle permet d'effacer des tables de configuration d'un équipement les voisins qui sont devenus inaccessibles (panne, changement d'adresse,...). Si un routeur devient inaccessible la table de routage peut être modifiée pour prendre en compte une autre route.</div>
* Configuration. La configuration automatique des équipements est l'un des attraits principaux d'IPv6. Plusieurs fonctionnalités du protocole de découverte des voisins sont mises en oeuvre :
* Découverte des routeurs. Ce protocole permet aux équipements de déterminer les routeurs qui sont sur leur lien physique. Dans IPv4, ces fonctionnalités sont assurées par le protocole ICMP Router Discovery.
* Découverte des préfixes. L'équipement apprend le ou les préfixes du réseau en fonction des annonces faites par les routeurs. En y ajoutant l'identifiant d'interface de l'équipement, celui-ci construit son ou ses adresses IPv6.
: Il n'existe pas d'équivalent pour le protocole IPv4 puisque les adresses sont trop courtes pour faire de l'auto-configuration.
* Détection des adresses dupliquées. Comme les adresses sont construites automatiquement, il existe des risques d'erreurs en cas d'identité de deux identifiants. Ce protocole teste qu'aucun autre équipement sur le lien ne possède la même adresse IPv6.
: Cette fonctionnalité est une évolution de l'ARP gratuit d'IPv4 émis à l'initialisation de l'interface.
* Découverte des paramètres. Ce protocole permet aux équipements d'apprendre les différents paramètres du lien physique, par exemple, la taille du MTU, le nombre de sauts maximal autorisé (valeur initiale du champ nombre de sauts), si la configuration automatique avec état (comme [[Configuration avec état :DHCPv6|DHCPv6]]) est active...
:Il n'existe pas d'équivalent en IPv4.
* Indication de redirection. Ce message est utilisé quand un routeur connaît une route meilleure (en nombre de sauts) pour aller à une destination.
:En IPv4 une indication de redirection ne peut servir qu'à corriger l'adresse du routeur utilisé pour accéder à une machine hors du réseau local. Les machines doivent connaître toutes les adresses correspondant aux réseaux locaux.
:Avec IPv6, la correspondance entre préfixe et réseau local est moins stricte. Il est prévu qu'un matériel ne connaisse pas tous les préfixes de son réseau local (si celui-ci est partagé par plusieurs préfixes), ou qu'un préfixe soit partagé entre plusieurs liens (une généralisation du modèle des réseaux logiques d'IP sur ATM). Dans certaines configurations, la machine émettra ses paquets au routeur alors que le destinataire se trouve sur le même segment que l'émetteur. Si c'est le cas, le routeur émettra un message de redirection pour que la suite du dialogue se fasse directement (cf. exemples [[Découverte_de_voisins#IR|Indication de redirection]]).
:Dans le cas le plus extrême, on peut imaginer en IPv6 qu'un équipement peut être configuré pour dialoguer uniquement avec son routeur par défaut. ICMPv6 «redirect» est alors utilisé pour informer l'équipement des destinataires sur le même lien.

= Données véhiculées par les messages =

L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier la plupart des données utilise un format d'options commun, ce qui simplifie la mise en oeuvre du protocole. Le format contient les champs type, longueur en mots de 64 bits, données. La faible précision du champ longueur va introduire une perte de place. En contre-partie, elle va permettre aussi un alignement des options sur des mots de 64 bits, ce qui optimise leur traitement.

En plus des cinq options générales décrites dans le tableau Utilisation des options dans les messages de découverte des voisins, il existe d'autres options spécifiques pour la mobilité et les réseaux NBMA (''Non Broadcast Multiple Access'') comme ATM ou Frame Relay.

{|
|+ Utilisation des options dans les messages de découverte des voisins
| width = 150 | || width = 100 |[[#RS|sollicitation du]] || width = 100 |[[#RA|annonce du]] || width = 100 |[[#NS|sollicitation]] ||width = 100 | [[#NA|annonce]] ||width = 100 |[[#IR|indication de]]
|-
| || [[#RS|routeur]] || [[#RA|routeur]] || [[#NS|d'un voisin]] || [[#NA|d'un voisin]] || [[#IR|redirection]]
|-style="background:silver"
|[[#physique |adresse physique de la source]] || présent || présent || présent || ||
|-
|[[#physique |adresse physique de la cible]] || || || || présent || présent
|-style="background:silver"
|[[#information|information sur le préfixe]] || || ≥ 1 || || ||
|-
|[[#redirigee |en-tête redirigée]] || || || || || présent
|-style="background:silver"
| [[#MTU |MTU]] || || possible || || ||
|}

=== <div id="physique">Adresse physique de la source/cible</div> ===

[[image:Fig5-1.png|thumb|right|300px|Figure 5-1 ''Format de l'option adresse physique source/cible'']]

La figure Format de l'option adresse physique source/cible donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.

Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.

== <div id="information">Information sur le préfixe</div> ==

[[image:Fig5-2.png|thumb|right|300px|Figure 5-2 ''Format de l'option information sur le préfixe'']]

Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Le champ type vaut 3 et le champ longueur vaut 4. La figure Format de l'option information sur le préfixe donne le format de l'option :

* Le champ lg.préfixe indique combien de bits sont significatifs pour le préfixe annoncé dans un champ suivant.
* Le bit <tt>L</tt> indique, quand il est à 1, que le préfixe permet d'indiquer que tous les autres équipements partageant le même préfixe sont sur le même lien. L'émetteur peut donc directement les joindre. Dans le cas contraire, l'équipement émet le paquet vers le routeur. Si ce dernier sait que l'équipement émetteur peut joindre directement le destinataire, il émettra un message ICMPv6 d'indication de redirection.
* Le bit <tt>A</tt> indique, quand il est à 1, que le préfixe annoncé peut être utilisé pour construire l'adresse de l'équipement.
* Le bit <tt>R</tt>, indique, quand il est à 1, que le champ préfixe contient l'adresse globale d'un routeur «agent mère». Les bits de poids fort peuvent toujours être utilisés pour construire un préfixe.
* Le champ durée de validité indique en secondes la durée pendant laquelle le préfixe est valide.
* Le champ durée préférable indique la durée en secondes pendant laquelle une adresse construite avec le protocole de configuration sans état demeure «préférable» (cf. [[Durée de vie des adresses]]).

Pour ces deux champs, une valeur de <tt>0xffffffff</tt> représente une durée infinie. Ces champs peuvent servir dans la phase de passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.
* Le champ réservé permet d'aligner le préfixe sur une frontière de mot de 64 bits.
* Le champ préfixe contient la valeur de préfixe annoncé sur le lien. Pour maintenir un alignement sur 64 bits pour le reste des données du paquet, ce champ a une longueur fixe de 128 bits.

== <div id="redirigee">En-tête redirigée</div> ==

[[image:Fig5-3.png|thumb|right|300px|Figure 5-3 ''Format de l'option en-tête redirigée'']]

Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.

Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible.

== <div id="MTU">MTU</div> ==

[[image:Fig5-4.png|thumb|right|300px|Figure 5-4 ''Format de l'option MTU'']]

Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure Format de l'option MTU donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.

Le champ type vaut 5 et le champ longueur 1.

= Messages de découverte de voisins =

Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et un dernier pour la redirection. Chacun de ces messages peut contenir des options.

== <div id="RS">Sollicitation du routeur</div> ==

[[image:Fig5-5.png|thumb|right|300px|Figure 5-5 ''Format des paquets de sollicitation du routeur'']]

Le message de sollicitation d'un routeur (cf. figure Format des paquets de sollicitation du routeur) est émis par un équipement au démarrage pour recevoir plus rapidement des informations du routeur. Ce message est émis à l'adresse IPv6 de multicast réservée aux routeurs sur le même lien <tt>ff02::2</tt>. Si l'équipement ne connaît pas encore son adresse source, l'adresse non spécifiée est utilisée.

Le champ option contient normalement l'adresse physique de l'équipement.

== <div id="RA">Annonce du routeur</div> ==

[[image:Fig5-6.png|thumb|right|300px|Figure 5-6 ''Format des paquets d'annonce du routeur'']]

Ce message (cf. figure Format des paquets d'annonce du routeur) est émis périodiquement par les routeurs ou en réponse à un message de sollicitation d'un routeur par un équipement. Le champ adresse source contient l'adresse locale au lien du routeur, le champ destination contient soit l'adresse de l'équipement qui a émis la sollicitation, soit l'adresse de toutes les stations (<tt>ff02::01</tt>).

Un champ saut max. non nul donne la valeur qui pourrait être placée dans le champ nombre de sauts des paquets émis. Le bit <tt>M</tt> indique qu'une adresse de l'équipement doit être obtenue avec un protocole de configuration (cf. [[Configuration avec état :DHCPv6]]). Le bit <tt>O</tt> indique aussi la présence d'un service de configuration mais pour la récupération d'informations autres que l'adresse. Si l'adresse ne peut être obtenue d'un serveur, l'équipement procède à une configuration sans état en concaténant aux préfixes qu'il connaît son identifiant d'interface. Le bit <tt>H</tt> indique que le routeur peut être utilisé comme «agent mère» pour un noeud mobile (cf. [[Avertissement de l'agent mère]]).

Le champ durée de vie du routeur donne, en secondes, la période pendant laquelle l'équipement annonçant effectuera les fonctions de routeur par défaut. La valeur maximale correspond à 18 heures 12 minutes, mais comme ce message est émis périodiquement il n'y a pas de limite théorique à la durée de vie d'un routeur. Une valeur de <tt>0</tt> indique que l'équipement ne remplit pas les fonctions de routeur par défaut. Cette durée de vie ne s'applique pas aux options que ce message véhicule.

Le champ durée d'accessibilité indique la durée en millisecondes pendant laquelle une information contenue dans le cache de la machine peut être considérée comme valide (par exemple, la table de correspondance entre adresse IPv6 et adresse physique). Au bout de cette période, un message de détection d'inaccessibilité est émis pour vérifier la pertinence de l'information.

Le champ temporisation de retransmission donne en millisecondes la période entre deux émissions non sollicitées de ce message. Il sert aux autres équipements pour détecter une inaccessibilité du routeur.

Ce message peut véhiculer les options :

* adresse physique de la source,
* MTU,
* information sur le préfixe (une ou plus).

== <div id="NS">Sollicitation d'un voisin</div> ==

[[image:Fig5-7.png|thumb|right|300px|Figure 5-7 ''Format des paquets de sollicitation d'un voisin'']]

Ce message (cf. figure Format des paquets de sollicitation d'un voisin) permet d'obtenir des informations d'un équipement voisin, c'est-à-dire situé sur le même lien physique (ou connecté via des ponts). Le message peut lui être explicitement envoyé ou émis sur une adresse de diffusion. Dans le cas de la détermination de l'adresse physique, il correspond à la requête ARP du protocole IPv4.

Le champ adresse source du paquet IPv6 contient soit l'adresse locale au lien adresse lien-local, soit une adresse globale, soit l'adresse non spécifiée. Le champ destination contient soit l'adresse de multicast sollicité correspondant à l'adresse recherchée (cf. [[Adressage_multicast#Identifiant_de_groupe|Identifiant de groupe]]), soit l'adresse de l'équipement (dans le cas d'une détection d'inaccessibilité des voisins, NUD )

Le champ adresse de la cible contient l'adresse IPv6 de l'équipement cherché. Le champ option contient en général l'adresse physique de la source.

== <div id="NA">Annonce d'un voisin</div> ==

[[image:Fig5-8.png|thumb|right|300px|Figure 5-8 ''Format des paquets d'annonce d'un voisin'']]

Ce message (cf. figure Format des paquets d'annonce d'un voisin) est émis en réponse à une sollicitation, mais il peut aussi être émis spontanément pour propager une information de changement d'adresse physique, ou de statut «routeur». Dans le cas de la détermination d'adresse physique, il correspond à la réponse ARP pour le protocole IPv4.

* Le bit <tt>R</tt> est mis à 1 si l'émetteur est un routeur. Ce bit est utilisé pour permettre la détection d'un routeur qui redevient un équipement ordinaire.
* Le bit <tt>S</tt> mis à 1 indique que cette annonce est émise en réponse à une sollicitation.
* Le bit <tt>O</tt> mis à 1 indique que cette annonce doit effacer les informations précédentes qui se trouvent dans les caches des autres équipements, en particulier la table contenant les adresses physiques.
* Le champ adresse de la cible contient, si le bit <tt>S</tt> est à 1, la valeur du champ adresse de la cible de la sollicitation auquel ce message répond. Si le bit <tt>S</tt> est à 0, ce champ contient l'adresse IPv6 lien-local de l'équipement émetteur.
* L'option adresse physique de la cible contient l'adresse physique de l'émetteur.

== <div id="IR">Indication de redirection</div> ==

La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure Routage par défaut non optimal).

[[image:Fig5-9.png|thumb|right|300px|Figure 5-9 ''Format des paquets d'indication de redirection'']]

Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe.

La figure Format des paquets d'indication de redirection donne le format du message :

* Le champ adresse cible contient l'adresse IPv6 de l'équipement vers lequel les paquets doivent être émis.
* Le champ adresse destination contient l'adresse IPv6 de l'équipement pour lequel la redirection s'applique.

Dans le cas de la redirection vers un équipement se situant sur le même lien, l'adresse cible et la destination sont identiques.

Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé.

{{suivi|Protocoles de Niveau 4|Protocoles de Niveau 4|Exemples de découverte de voisins|Exemples de découverte de voisins}}

Découverte de voisins

2006-06-08T09:28:03Z

Bruno Stévant: /* <div id="NS">Sollicitation d'un voisin</div> */

{{suivi|Protocoles de Niveau 4|Protocoles de Niveau 4|Exemples de découverte de voisins|Exemples de découverte de voisins}}

__TOC__

Le protocole de découverte des voisins neighbor discovery permet à un équipement de s'intégrer dans l'environnement local, c'est-à-dire le lien sur lequel sont physiquement transmis les paquets IPv6. Il permet de dialoguer avec les équipements connectés au même support (stations et routeurs). Il ne s'agit pas pour un équipement de connaître exactement la liste de tous les autres équipements connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.

Le protocole utilise cinq types de messages ICMPv6 (voir [[Modèle:Tableau ICMPv6|Valeurs des champs type et code d'ICMPv6]]). Le champ nombre de sauts de l'en-tête IPv6 contient la valeur 255 -- il peut sembler paradoxal d'utiliser une valeur aussi grande pour des datagrammes qui ne doivent pas être routés hors du lien physique ; en fait si un équipement reçoit un datagramme avec une valeur plus petite, cela signifie que l'information provient d'un autre réseau et que le datagramme doit être rejeté.

Le protocole réalise les différentes fonctions :

* Résolution d'adresses. Le principe est très proche du protocole ARP que l'on trouve avec IPv4. La principale différence vient de l'emploi de messages standards ICMPv6 à la place de la définition d'un autre protocole de niveau 3. Cela confère une plus grande souplesse d'utilisation en particulier sur les réseaux qui ne supportent pas la diffusion. Comme pour IPv4, ce protocole construit des tables de mise en correspondance entre les adresses IPv6 et physiques.
* <div id="NUD">Détection d'inaccessibilité des voisins ou NUD (''Neighbor Unreachability Detection''). Cette fonction n'existe pas en IPv4. Elle permet d'effacer des tables de configuration d'un équipement les voisins qui sont devenus inaccessibles (panne, changement d'adresse,...). Si un routeur devient inaccessible la table de routage peut être modifiée pour prendre en compte une autre route.</div>
* Configuration. La configuration automatique des équipements est l'un des attraits principaux d'IPv6. Plusieurs fonctionnalités du protocole de découverte des voisins sont mises en oeuvre :
* Découverte des routeurs. Ce protocole permet aux équipements de déterminer les routeurs qui sont sur leur lien physique. Dans IPv4, ces fonctionnalités sont assurées par le protocole ICMP Router Discovery.
* Découverte des préfixes. L'équipement apprend le ou les préfixes du réseau en fonction des annonces faites par les routeurs. En y ajoutant l'identifiant d'interface de l'équipement, celui-ci construit son ou ses adresses IPv6.
: Il n'existe pas d'équivalent pour le protocole IPv4 puisque les adresses sont trop courtes pour faire de l'auto-configuration.
* Détection des adresses dupliquées. Comme les adresses sont construites automatiquement, il existe des risques d'erreurs en cas d'identité de deux identifiants. Ce protocole teste qu'aucun autre équipement sur le lien ne possède la même adresse IPv6.
: Cette fonctionnalité est une évolution de l'ARP gratuit d'IPv4 émis à l'initialisation de l'interface.
* Découverte des paramètres. Ce protocole permet aux équipements d'apprendre les différents paramètres du lien physique, par exemple, la taille du MTU, le nombre de sauts maximal autorisé (valeur initiale du champ nombre de sauts), si la configuration automatique avec état (comme [[Configuration avec état :DHCPv6|DHCPv6]]) est active...
:Il n'existe pas d'équivalent en IPv4.
* Indication de redirection. Ce message est utilisé quand un routeur connaît une route meilleure (en nombre de sauts) pour aller à une destination.
:En IPv4 une indication de redirection ne peut servir qu'à corriger l'adresse du routeur utilisé pour accéder à une machine hors du réseau local. Les machines doivent connaître toutes les adresses correspondant aux réseaux locaux.
:Avec IPv6, la correspondance entre préfixe et réseau local est moins stricte. Il est prévu qu'un matériel ne connaisse pas tous les préfixes de son réseau local (si celui-ci est partagé par plusieurs préfixes), ou qu'un préfixe soit partagé entre plusieurs liens (une généralisation du modèle des réseaux logiques d'IP sur ATM). Dans certaines configurations, la machine émettra ses paquets au routeur alors que le destinataire se trouve sur le même segment que l'émetteur. Si c'est le cas, le routeur émettra un message de redirection pour que la suite du dialogue se fasse directement (cf. exemples [[Découverte_de_voisins#IR|Indication de redirection]]).
:Dans le cas le plus extrême, on peut imaginer en IPv6 qu'un équipement peut être configuré pour dialoguer uniquement avec son routeur par défaut. ICMPv6 «redirect» est alors utilisé pour informer l'équipement des destinataires sur le même lien.

= Données véhiculées par les messages =

L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier la plupart des données utilise un format d'options commun, ce qui simplifie la mise en oeuvre du protocole. Le format contient les champs type, longueur en mots de 64 bits, données. La faible précision du champ longueur va introduire une perte de place. En contre-partie, elle va permettre aussi un alignement des options sur des mots de 64 bits, ce qui optimise leur traitement.

En plus des cinq options générales décrites dans le tableau Utilisation des options dans les messages de découverte des voisins, il existe d'autres options spécifiques pour la mobilité et les réseaux NBMA (''Non Broadcast Multiple Access'') comme ATM ou Frame Relay.

{|
|+ Utilisation des options dans les messages de découverte des voisins
| width = 150 | || width = 100 |[[#RS|sollicitation du]] || width = 100 |[[#RA|annonce du]] || width = 100 |[[#NS|sollicitation]] ||width = 100 | [[#NA|annonce]] ||width = 100 |[[#IR|indication de]]
|-
| || [[#RS|routeur]] || [[#RA|routeur]] || [[#NS|d'un voisin]] || [[#NA|d'un voisin]] || [[#IR|redirection]]
|-style="background:silver"
|[[#physique |adresse physique de la source]] || présent || présent || présent || ||
|-
|[[#physique |adresse physique de la cible]] || || || || présent || présent
|-style="background:silver"
|[[#information|information sur le préfixe]] || || ≥ 1 || || ||
|-
|[[#redirigee |en-tête redirigée]] || || || || || présent
|-style="background:silver"
| [[#MTU |MTU]] || || possible || || ||
|}

=== <div id="physique">Adresse physique de la source/cible</div> ===

[[image:Fig5-1.png|thumb|right|300px|Figure 5-1 ''Format de l'option adresse physique source/cible'']]

La figure Format de l'option adresse physique source/cible donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.

Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.

== <div id="information">Information sur le préfixe</div> ==

[[image:Fig5-2.png|thumb|right|300px|Figure 5-2 ''Format de l'option information sur le préfixe'']]

Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Le champ type vaut 3 et le champ longueur vaut 4. La figure Format de l'option information sur le préfixe donne le format de l'option :

* Le champ lg.préfixe indique combien de bits sont significatifs pour le préfixe annoncé dans un champ suivant.
* Le bit <tt>L</tt> indique, quand il est à 1, que le préfixe permet d'indiquer que tous les autres équipements partageant le même préfixe sont sur le même lien. L'émetteur peut donc directement les joindre. Dans le cas contraire, l'équipement émet le paquet vers le routeur. Si ce dernier sait que l'équipement émetteur peut joindre directement le destinataire, il émettra un message ICMPv6 d'indication de redirection.
* Le bit <tt>A</tt> indique, quand il est à 1, que le préfixe annoncé peut être utilisé pour construire l'adresse de l'équipement.
* Le bit <tt>R</tt>, indique, quand il est à 1, que le champ préfixe contient l'adresse globale d'un routeur «agent mère». Les bits de poids fort peuvent toujours être utilisés pour construire un préfixe.
* Le champ durée de validité indique en secondes la durée pendant laquelle le préfixe est valide.
* Le champ durée préférable indique la durée en secondes pendant laquelle une adresse construite avec le protocole de configuration sans état demeure «préférable» (cf. [[Durée de vie des adresses]]).

Pour ces deux champs, une valeur de <tt>0xffffffff</tt> représente une durée infinie. Ces champs peuvent servir dans la phase de passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.
* Le champ réservé permet d'aligner le préfixe sur une frontière de mot de 64 bits.
* Le champ préfixe contient la valeur de préfixe annoncé sur le lien. Pour maintenir un alignement sur 64 bits pour le reste des données du paquet, ce champ a une longueur fixe de 128 bits.

== <div id="redirigee">En-tête redirigée</div> ==

[[image:Fig5-3.png|thumb|right|300px|Figure 5-3 ''Format de l'option en-tête redirigée'']]

Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.

Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible.

== <div id="MTU">MTU</div> ==

[[image:Fig5-4.png|thumb|right|300px|Figure 5-4 ''Format de l'option MTU'']]

Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure Format de l'option MTU donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.

Le champ type vaut 5 et le champ longueur 1.

= Messages de découverte de voisins =

Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et un dernier pour la redirection. Chacun de ces messages peut contenir des options.

== <div id="RS">Sollicitation du routeur</div> ==

[[image:Fig5-5.png|thumb|right|300px|Figure 5-5 ''Format des paquets de sollicitation du routeur'']]

Le message de sollicitation d'un routeur (cf. figure Format des paquets de sollicitation du routeur) est émis par un équipement au démarrage pour recevoir plus rapidement des informations du routeur. Ce message est émis à l'adresse IPv6 de multicast réservée aux routeurs sur le même lien <tt>ff02::2</tt>. Si l'équipement ne connaît pas encore son adresse source, l'adresse non spécifiée est utilisée.

Le champ option contient normalement l'adresse physique de l'équipement.

== <div id="RA">Annonce du routeur</div> ==

[[image:Fig5-6.png|thumb|right|300px|Figure 5-6 ''Format des paquets d'annonce du routeur'']]

Ce message (cf. figure Format des paquets d'annonce du routeur) est émis périodiquement par les routeurs ou en réponse à un message de sollicitation d'un routeur par un équipement. Le champ adresse source contient l'adresse locale au lien du routeur, le champ destination contient soit l'adresse de l'équipement qui a émis la sollicitation, soit l'adresse de toutes les stations (<tt>ff02::01</tt>).

Un champ saut max. non nul donne la valeur qui pourrait être placée dans le champ nombre de sauts des paquets émis. Le bit <tt>M</tt> indique qu'une adresse de l'équipement doit être obtenue avec un protocole de configuration (cf. [[Configuration avec état :DHCPv6]]). Le bit <tt>O</tt> indique aussi la présence d'un service de configuration mais pour la récupération d'informations autres que l'adresse. Si l'adresse ne peut être obtenue d'un serveur, l'équipement procède à une configuration sans état en concaténant aux préfixes qu'il connaît son identifiant d'interface. Le bit <tt>H</tt> indique que le routeur peut être utilisé comme «agent mère» pour un noeud mobile (cf. [[Avertissement de l'agent mère]]).

Le champ durée de vie du routeur donne, en secondes, la période pendant laquelle l'équipement annonçant effectuera les fonctions de routeur par défaut. La valeur maximale correspond à 18 heures 12 minutes, mais comme ce message est émis périodiquement il n'y a pas de limite théorique à la durée de vie d'un routeur. Une valeur de <tt>0</tt> indique que l'équipement ne remplit pas les fonctions de routeur par défaut. Cette durée de vie ne s'applique pas aux options que ce message véhicule.

Le champ durée d'accessibilité indique la durée en millisecondes pendant laquelle une information contenue dans le cache de la machine peut être considérée comme valide (par exemple, la table de correspondance entre adresse IPv6 et adresse physique). Au bout de cette période, un message de détection d'inaccessibilité est émis pour vérifier la pertinence de l'information.

Le champ temporisation de retransmission donne en millisecondes la période entre deux émissions non sollicitées de ce message. Il sert aux autres équipements pour détecter une inaccessibilité du routeur.

Ce message peut véhiculer les options :

* adresse physique de la source,
* MTU,
* information sur le préfixe (une ou plus).

== <div id="NS">Sollicitation d'un voisin</div> ==

[[image:Fig5-7.png|thumb|right|300px|Figure 5-7 ''Format des paquets de sollicitation d'un voisin'']]

Ce message (cf. figure Format des paquets de sollicitation d'un voisin) permet d'obtenir des informations d'un équipement voisin, c'est-à-dire situé sur le même lien physique (ou connecté via des ponts). Le message peut lui être explicitement envoyé ou émis sur une adresse de diffusion. Dans le cas de la détermination de l'adresse physique, il correspond à la requête ARP du protocole IPv4.

Le champ adresse source du paquet IPv6 contient soit l'adresse locale au lien adresse lien-local, soit une adresse globale, soit l'adresse non spécifiée. Le champ destination contient soit l'adresse de multicast sollicité correspondant à l'adresse recherchée (cf. [[Adressage_multicast#Identifiant_de_groupe|Identifiant de groupe]]), soit l'adresse de l'équipement (dans le cas d'une détection d'inaccessibilité des voisins, NUD )

Le champ adresse de la cible contient l'adresse IPv6 de l'équipement cherché. Le champ option contient en général l'adresse physique de la source.

== <div id="NA">Annonce d'un voisin</div> ==

[[image:Fig5-8.png|thumb|right|300px|Figure 5-8 ''Format des paquets d'annonce d'un voisin'']]

Ce message (cf. figure Format des paquets d'annonce d'un voisin) est émis en réponse à une sollicitation, mais il peut aussi être émis spontanément pour propager une information de changement d'adresse physique, ou de statut «routeur». Dans le cas de la détermination d'adresse physique, il correspond à la réponse ARP pour le protocole IPv4.

* Le bit <tt>R</tt> est mis à 1 si l'émetteur est un routeur. Ce bit est utilisé pour permettre la détection d'un routeur qui redevient un équipement ordinaire.
* Le bit <tt>S</tt> mis à 1 indique que cette annonce est émise en réponse à une sollicitation.
* Le bit <tt>O</tt> mis à 1 indique que cette annonce doit effacer les informations précédentes qui se trouvent dans les caches des autres équipements, en particulier la table contenant les adresses physiques.
* Le champ adresse de la cible contient, si le bit <tt>S</tt> est à 1, la valeur du champ adresse de la cible de la sollicitation auquel ce message répond. Si le bit <tt>S</tt> est à 0, ce champ contient l'adresse IPv6 lien-local de l'équipement émetteur.
* L'option adresse physique de la cible contient l'adresse physique de l'émetteur.

== <div id="IR">Indication de redirection</div> ==

La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure [[Routage par défaut non optimal]]).

[[image:Fig5-9.png|thumb|right|300px|Figure 5-9 ''Format des paquets d'indication de redirection'']]

Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe.

La figure Format des paquets d'indication de redirection donne le format du message :

* Le champ adresse cible contient l'adresse IPv6 de l'équipement vers lequel les paquets doivent être émis.
* Le champ adresse destination contient l'adresse IPv6 de l'équipement pour lequel la redirection s'applique.

Dans le cas de la redirection vers un équipement se situant sur le même lien, l'adresse cible et la destination sont identiques.

Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé.

{{suivi|Protocoles de Niveau 4|Protocoles de Niveau 4|Exemples de découverte de voisins|Exemples de découverte de voisins}}

Talk:Lien-local

2006-06-08T08:42:04Z

Bruno Stévant:

je n'aime pas le schéma ... illisible en partie (même si je suis censé savoir ce qu'est un adresse link local)

A+

+BT.

OK, modifié.

MOOC:Exercices

2006-06-04T20:36:55Z

Bruno Stévant:

[[Préambule]]
[[Introduction]]

Main Page

2006-05-23T14:06:48Z

Bruno Stévant:

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 nous avons décidé avec les éditions O'Reilly et le [http://www.g6.asso.fr G6]
et le support technique du [http://www.point6.net Point6]
d'en faire une version en ligne (accessible en IPv4 et IPv6). Ce serveur reprend
intégralement la quatrième édition du livre IPv6 théorie et Pratique paru en Novembre
2005 chez O'Reilly. 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.

'''Une session de mise à jour du livre se déroulera à Angers les 8, 9 et 10 Juin, suivant l'AG de l'association G6'''

Par ailleurs, un [http://www.point6.net/~toutain/phpBB2 forum] a été ouvert pour permettre une discussion
autour du livre ou demander des explications. Les experts du G6 pourront répondre. Vous devez créer un compte
(register) avant de pouvoir poster une question ou une remarque.

Bonne Lecture

Gisèle Cizault

Main Page

2006-05-23T14:06:26Z

Bruno Stévant:

Talk:Nommage inverse : de l'adresse vers les noms

2006-04-19T13:08:13Z

Bruno Stévant:

* Il y une erreur dans le schémas pour le préfixe de l'AFNIC : il doit avoir une longueur /48.
* Les entrées ip6.int sont dépréciées depuis la [ftp://ftp.rfc-editor.org/in-notes/rfc4159.txt RFC 4159]

Talk:Nommage inverse : de l'adresse vers les noms

2006-04-13T15:22:44Z

Bruno Stévant:

Il y une erreur dans le schémas pour le préfixe de l'AFNIC : il doit avoir une longueur /48.

Utilisation du multicast

2006-04-12T17:02:58Z

Bruno Stévant: /* in2multi6 */

{{suivi| mini-ping | mini-ping | Programmation avancée | Programmation avancée }}
La programmation avec les groupes multicast n'est pas standardisée en IPv4. La nouvelle API "socket" propose un ensemble de structures et appels systèmes pour étendre l'interface de programmation sockets aux applications utilisant le multicast. Cet exemple va illustrer ce point.

Le but des deux programmes est d'échanger des données par multicast. Le programme <tt>in2multi6</tt> diffuse les données lues en entrée ("standard input") vers un groupe multicast donné. Le programme <tt>multi2out6</tt> écoute les paquets transmis dans ce groupe et les copie sur la sortie standard ("stdout").

==multi2out6==

Pour ce faire <tt>multi2out6</tt> va faire des appels systèmes qui vont produire des paquets d'abonnement (et de désabonnement) à un groupe multicast. L'abonnement sera réalisé grâce à l'envoi de deux messages ICMPv6 successifs de type 131, c'est-à-dire des "rapports d'abonnement". Puis les messages émis dans le groupe sont reçus par le programme. Lorsque le programme s'arrête, le code de l'interface va automatiquement provoquer l'émission d'un message de réduction d'un groupe de multicast (132).

Le programme multi2out6 est appelé de la manière suivante :

'''multi2out6 [-i interface] <adresse de groupe multicast>'''

Voici le code complet du programme. Le port utilisé (ligne 15) est quelconque mais ne doit bien sûr pas correspondre à un service déjà existant.

1| #include <sys/types.h>
2| #include <sys/socket.h>
3| #include <netinet/in.h>
4| #include <arpa/inet.h>
5| #include <stdio.h>
6| #include <signal.h>
7| #include <unistd.h>
8|
9| #ifndef SO_REUSEPORT
10| #define SO_REUSEPORT SO_REUSEADDR
11| #endif
12|
13| struct sockaddr_in6 sin6;
14|
15| #define IPPORT 54321
16|
17| void Perror(const char *c)
18| {
19| perror(c);
20| exit(1);
21| }
22|
23| void Usage ()
24| {
25| fprintf(stderr, "%s\n", "Usage: multi2out6 [-i interface] addr");
26| exit(1);
27| }
28|
29| void BrokenPipe(int Signal)
30| {
31| signal(SIGPIPE, BrokenPipe);
32| return;
33| }
34|

La partie principale du programme traite les options éventuelles. En fait, il n'y en a qu'une, le choix de l'interface à abonner au groupe multicast. Une fois ces operations effectuées, il faut créer et attacher une socket à une adresse. Ces opérations sont réalisées par l'utilisation des fonctions classiques socket et bind.

On utilise une structure de données spéciale pour stocker l'adresse multicast du groupe (définie dans <tt>netinet/in.h</tt>) :

struct ipv6_mreq {
struct in6_addr ipv6mr_multiaddr; /* IPv6 mcast address of group */
unsigned int ipv6mr_interface; /* local IPv6 address of interface */
};

35| int main(int argc, char **argv)
36| {
37| struct ipv6_mreq mreq;
38| int cc, ccb, ch, s;
39| char buf[10240];
40| u_int one = 1;
41| u_int ifi = 0;
42|
43| signal(SIGPIPE, BrokenPipe);
44| while ((ch = getopt(argc, argv, "i:")) != -1)
45| switch(ch) {
46| case 'i':
47| if (sscanf(optarg, "%u\0", &ifi) != 1 &&
48| (ifi = if_nametoindex(optarg)) == 0)
49| Usage();
50| break;
51| default:
52| Usage();
53| }
54| argc -= optind;
55| argv += optind;
56| if (argc != 1)
57| Usage();
58|
59| if ((s = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP)) < 0)
60| Perror("socket");
61| setsockopt(s, SOL_SOCKET, SO_REUSEPORT, &one, sizeof(one));
62|
63| #ifdef SIN6_LEN
64| sin6.sin6_len = sizeof(sin6);
65| #endif
66| sin6.sin6_family = AF_INET6;
67| sin6.sin6_port = htons(IPPORT);
68| if (bind(s, (struct sockaddr *)&sin6, sizeof(sin6)) < 0)
69| Perror("bind");

La fonction <tt>inet_pton</tt> va permettre la conversion du nom de groupe passé en option sous une forme textuelle (par exemple <tt>ff12::1234:5678</tt>) en forme numérique. Le résultat est directement stocké dans la variable <tt>mreq</tt> qui sera utilisée par la commande <tt>setsockop</tt>. On passe en paramètre à cette fonction l'option <tt>IPV6_JOIN_GROUP</tt> avec la variable <tt>mreq</tt>. À partir de ce moment, il y a émission de deux messages d'abonnement. La boucle qui suit va permettre la lecture des informations envoyées sur le groupe auquel on vient de s'abonner et les afficher sur la sortie standard ainsi que leur longueur sur la sortie erreur standard.

70| if (inet_pton(AF_INET6, *argv, &mreq.ipv6mr_multiaddr) != 1)
71| Usage();
72| mreq.ipv6mr_interface = ifi;
73| if (setsockopt(s,IPPROTO_IPV6, IPV6_JOIN_GROUP, &mreq, sizeof(mreq)) < 0)
74| Perror("setsockopt IPV6_JOIN_GROUP");
75| for (;;) {
76| cc = read(s, buf, 10240);
77| if (cc < 0)
78| Perror("read socket");
79| if (cc == 0) {
80| fprintf(stderr, "..\n");
81| exit (0);
82| }
83| ccb = write(1, buf, cc);
84| if (ccb != cc)
85| Perror("write file");
86| fprintf(stderr, "<-%d-\n", cc);
87| }
88| }

Lorsque le programme s'arrête, un <tt>close(s)</tt> implicite a lieu, et le code de l'interface va envoyer un message de réduction de groupe si elle est la dernière à avoir envoyé un rapport d'abonnement au groupe.

==in2multi6==

Le programme est appelé de la manière suivante :

'''in2multi6 [-i interface][-h max-hop-count][-l loop] <adresse de groupe multicast>'''

Le code est relativement simple, principalement une analyse des arguments, le positionnement d'option et une boucle lecture--émission. En effet il n'est pas nécessaire de s'abonner pour faire de l'émission multicast.

Il y a quatre arguments, trois optionnels qui sont l'interface d'émission (nom ou index numérique), le "ttl" mis dans les paquets multicast (voir le manuel de la primitive <tt>readv</tt>), et un drapeau qui sert à dire si la machine émettrice reçoit ou non les paquet émis. Le dernier argument est l'adresse du groups sous forme numérique.

Voici le code complet du programme. Le port utilisé (ligne 10) est naturellement celui de <tt>in2multi6</tt>.

1| #include <sys/types.h>
2| #include <sys/socket.h>
3| #include <netinet/in.h>
4| #include <arpa/inet.h>
5| #include <stdio.h>
6| #include <unistd.h>
7|
8| struct sockaddr_in6 sin6;
9|
10| #define IPPORT 54321
11|
12| void Perror(const char *c)
13| {
14| perror(c);
15| exit(1);
16| }
17|
18| void Usage ()
19| {
20| fprintf(stderr, "%s\n", "Usage: in2multi6 [-i interface][-h hop][-l loop] addr");
21| exit(1);
22| }
23|
24| int main(int argc, char **argv)
25| {
26| u_int hops = 1, /* as defined in rfc2553 */
27| loop = 1, /* as defined in rfc2553 */
28| ifi = 0;
29| int s, cc, ch;
30| char buf[1024];
31| struct in6_addr addr6;
32| extern char *optarg;
33| extern int optind;
34|
35| addr6 = in6addr_any;
36| if ((s = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP)) < 0)
37| Perror("socket");
38| while ((ch = getopt(argc, argv, "h:t:l:i:")) != -1)
39| switch(ch) {
40| case 'h':
41| case 't':
42| hops = atoi(optarg);
43| break;
44| case 'l':
45| loop = atoi(optarg);
46| break;
47| case 'i':
48| if (sscanf(optarg, "%u\0", &ifi) != 1) {
49| ifi = if_nametoindex(optarg);
50| if (ifi == 0)
51| Usage();
52| }
53| break;
54| default:
55| Usage();
56| }
57| argc -= optind;
58| argv += optind;
59| if (argc != 1 || inet_pton(AF_INET6, *argv, &addr6) <= 0)
60| Usage();
61| if (setsockopt(s, IPPROTO_IPV6, IPV6_MULTICAST_HOPS,
62| &hops, sizeof(hops)) < 0)
63| Perror("setsockopt IPV6_MULTICAST_HOPS");
64| if (setsockopt(s, IPPROTO_IPV6, IPV6_MULTICAST_LOOP,
65| &loop, sizeof(loop)) < 0)
66| Perror("setsockopt IPV6_MULTICAST_LOOP");
67| if (ifi && (setsockopt(s, IPPROTO_IPV6, IPV6_MULTICAST_IF,
68| &ifi, sizeof(u_int)) < 0))
69| Perror("setsockopt IPV6_MULTICAST_IF");
70|
71| #ifdef SIN6_LEN
72| sin6.sin6_len = sizeof(sin6);
73| #endif
74| sin6.sin6_family = AF_INET6;
75| sin6.sin6_addr = addr6;
76| sin6.sin6_port = htons(54321);
77|
78| for (;;) {
79| cc = read(0, buf, 1024);
80| if (cc < 0)
81| Perror("read file");
82| if (cc == 0) {
83| fprintf(stderr, ".\n", cc);
84| exit (0);
85| }
86| if (sendto(s, buf, cc, 0,
87| (struct sockaddr *)&sin6, sizeof(sin6)) < 0)
88| Perror("sendto");
89| fprintf(stderr, "-%d->\n", cc);
90| }
91| }
{{suivi| mini-ping | mini-ping | Programmation avancée | Programmation avancée }}

Utilisation du multicast

2006-04-10T16:15:09Z

Bruno Stévant: /* multi2out6 */

{{suivi| mini-ping | mini-ping | Programmation avancée | Programmation avancée }}
La programmation avec les groupes multicast n'est pas standardisée en IPv4. La nouvelle API "socket" propose un ensemble de structures et appels systèmes pour étendre l'interface de programmation sockets aux applications utilisant le multicast. Cet exemple va illustrer ce point.

Le but des deux programmes est d'échanger des données par multicast. Le programme <tt>in2multi6</tt> diffuse les données lues en entrée ("standard input") vers un groupe multicast donné. Le programme <tt>multi2out6</tt> écoute les paquets transmis dans ce groupe et les copie sur la sortie standard ("stdout").

==multi2out6==

Pour ce faire <tt>multi2out6</tt> va faire des appels systèmes qui vont produire des paquets d'abonnement (et de désabonnement) à un groupe multicast. L'abonnement sera réalisé grâce à l'envoi de deux messages ICMPv6 successifs de type 131, c'est-à-dire des "rapports d'abonnement". Puis les messages émis dans le groupe sont reçus par le programme. Lorsque le programme s'arrête, le code de l'interface va automatiquement provoquer l'émission d'un message de réduction d'un groupe de multicast (132).

Le programme multi2out6 est appelé de la manière suivante :

'''multi2out6 [-i interface] <adresse de groupe multicast>'''

Voici le code complet du programme. Le port utilisé (ligne 15) est quelconque mais ne doit bien sûr pas correspondre à un service déjà existant.

1| #include <sys/types.h>
2| #include <sys/socket.h>
3| #include <netinet/in.h>
4| #include <arpa/inet.h>
5| #include <stdio.h>
6| #include <signal.h>
7| #include <unistd.h>
8|
9| #ifndef SO_REUSEPORT
10| #define SO_REUSEPORT SO_REUSEADDR
11| #endif
12|
13| struct sockaddr_in6 sin6;
14|
15| #define IPPORT 54321
16|
17| void Perror(const char *c)
18| {
19| perror(c);
20| exit(1);
21| }
22|
23| void Usage ()
24| {
25| fprintf(stderr, "%s\n", "Usage: multi2out6 [-i interface] addr");
26| exit(1);
27| }
28|
29| void BrokenPipe(int Signal)
30| {
31| signal(SIGPIPE, BrokenPipe);
32| return;
33| }
34|

La partie principale du programme traite les options éventuelles. En fait, il n'y en a qu'une, le choix de l'interface à abonner au groupe multicast. Une fois ces operations effectuées, il faut créer et attacher une socket à une adresse. Ces opérations sont réalisées par l'utilisation des fonctions classiques socket et bind.

On utilise une structure de données spéciale pour stocker l'adresse multicast du groupe (définie dans <tt>netinet/in.h</tt>) :

struct ipv6_mreq {
struct in6_addr ipv6mr_multiaddr; /* IPv6 mcast address of group */
unsigned int ipv6mr_interface; /* local IPv6 address of interface */
};

35| int main(int argc, char **argv)
36| {
37| struct ipv6_mreq mreq;
38| int cc, ccb, ch, s;
39| char buf[10240];
40| u_int one = 1;
41| u_int ifi = 0;
42|
43| signal(SIGPIPE, BrokenPipe);
44| while ((ch = getopt(argc, argv, "i:")) != -1)
45| switch(ch) {
46| case 'i':
47| if (sscanf(optarg, "%u\0", &ifi) != 1 &&
48| (ifi = if_nametoindex(optarg)) == 0)
49| Usage();
50| break;
51| default:
52| Usage();
53| }
54| argc -= optind;
55| argv += optind;
56| if (argc != 1)
57| Usage();
58|
59| if ((s = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP)) < 0)
60| Perror("socket");
61| setsockopt(s, SOL_SOCKET, SO_REUSEPORT, &one, sizeof(one));
62|
63| #ifdef SIN6_LEN
64| sin6.sin6_len = sizeof(sin6);
65| #endif
66| sin6.sin6_family = AF_INET6;
67| sin6.sin6_port = htons(IPPORT);
68| if (bind(s, (struct sockaddr *)&sin6, sizeof(sin6)) < 0)
69| Perror("bind");

La fonction <tt>inet_pton</tt> va permettre la conversion du nom de groupe passé en option sous une forme textuelle (par exemple <tt>ff12::1234:5678</tt>) en forme numérique. Le résultat est directement stocké dans la variable <tt>mreq</tt> qui sera utilisée par la commande <tt>setsockop</tt>. On passe en paramètre à cette fonction l'option <tt>IPV6_JOIN_GROUP</tt> avec la variable <tt>mreq</tt>. À partir de ce moment, il y a émission de deux messages d'abonnement. La boucle qui suit va permettre la lecture des informations envoyées sur le groupe auquel on vient de s'abonner et les afficher sur la sortie standard ainsi que leur longueur sur la sortie erreur standard.

70| if (inet_pton(AF_INET6, *argv, &mreq.ipv6mr_multiaddr) != 1)
71| Usage();
72| mreq.ipv6mr_interface = ifi;
73| if (setsockopt(s,IPPROTO_IPV6, IPV6_JOIN_GROUP, &mreq, sizeof(mreq)) < 0)
74| Perror("setsockopt IPV6_JOIN_GROUP");
75| for (;;) {
76| cc = read(s, buf, 10240);
77| if (cc < 0)
78| Perror("read socket");
79| if (cc == 0) {
80| fprintf(stderr, "..\n");
81| exit (0);
82| }
83| ccb = write(1, buf, cc);
84| if (ccb != cc)
85| Perror("write file");
86| fprintf(stderr, "<-%d-\n", cc);
87| }
88| }

Lorsque le programme s'arrête, un <tt>close(s)</tt> implicite a lieu, et le code de l'interface va envoyer un message de réduction de groupe si elle est la dernière à avoir envoyé un rapport d'abonnement au groupe.

==in2multi6==

Le programme est appelé de la manière suivante :

'''in2multi6 [-i interface][-h max-hop-count][-l loop] <adresse de groupe multicast>'''

Le code est relativement simple, principalement une analyse des arguments, le positionnement d'option et une boucle lecture--émission. En effet il n'est pas nécessaire de s'abonner pour faire de l'émission multicast.

Il y a quatre arguments, trois optionnels qui sont l'interface d'émission (nom ou index numérique), le "ttl" mis dans les paquets multicast (voir le manuel de la primitive <tt>readv</tt>), et un drapeau qui sert à dire si la machine émettrice reçoit ou non les paquet émis. Le dernier argument est l'adresse du groups sous forme numérique.

Voici le code complet du programme. Le port utilisé (ligne 10) est naturellement celui de <tt>in2multi6</tt>.

1| #include <sys/types.h>
2| #include <sys/socket.h>
3| #include <netinet/in.h>
4| #include <arpa/inet.h>
5| #include <stdio.h>
6| #include <unistd.h>
7|
8| struct sockaddr_in6 sin6;
9|
10| #define IPPORT 54321
11|
12| void Perror(const char *c)
13| {
14| perror(c);
15| exit(1);
16| }
17|
18| void Usage ()
19| {
20| fprintf(stderr, "%s\n", "Usage: in2multi6 [-i interface][-h hop][-l loop] addr");
21| exit(1);
22| }
23|
24| main(int argc, char **argv)
25| {
26| u_int hops = 1, /* as defined in rfc2553 */
27| loop = 1, /* as defined in rfc2553 */
28| ifi = 0;
29| int s, cc, ch;
30| char buf[1024];
31| struct in6_addr addr6;
32| extern char *optarg;
33| extern int optind;
34|
35| addr6 = in6addr_any;
36| if ((s = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP)) < 0)
37| Perror("socket");
38| while ((ch = getopt(argc, argv, "h:t:l:i:")) != -1)
39| switch(ch) {
40| case 'h':
41| case 't':
42| hops = atoi(optarg);
43| break;
44| case 'l':
45| loop = atoi(optarg);
46| break;
47| case 'i':
48| if (sscanf(optarg, "%u\0", &ifi) != 1) {
49| ifi = if_nametoindex(optarg);
50| if (ifi == 0)
51| Usage();
52| }
53| break;
54| default:
55| Usage();
56| }
57| argc -= optind;
58| argv += optind;
59| if (argc != 1 || inet_pton(AF_INET6, *argv, &addr6) <= 0)
60| Usage();
61| if (setsockopt(s, IPPROTO_IPV6, IPV6_MULTICAST_HOPS,
62| &hops, sizeof(hops)) < 0)
63| Perror("setsockopt IPV6_MULTICAST_HOPS");
64| if (setsockopt(s, IPPROTO_IPV6, IPV6_MULTICAST_LOOP,
65| &loop, sizeof(loop)) < 0)
66| Perror("setsockopt IPV6_MULTICAST_LOOP");
67| if (ifi && (setsockopt(s, IPPROTO_IPV6, IPV6_MULTICAST_IF,
68| &ifi, sizeof(u_int)) < 0))
69| Perror("setsockopt IPV6_MULTICAST_IF");
70|
71| #ifdef SIN6_LEN
72| sin6.sin6_len = sizeof(sin6);
73| #endif
74| sin6.sin6_family = AF_INET6;
75| sin6.sin6_addr = addr6;
76| sin6.sin6_port = htons(54321);
77|
78| for (;;) {
79| cc = read(0, buf, 1024);
80| if (cc < 0)
81| Perror("read file");
82| if (cc == 0) {
83| fprintf(stderr, ".\n", cc);
84| exit (0);
85| }
86| if (sendto(s, buf, cc, 0,
87| (struct sockaddr *)&sin6, sizeof(sin6)) < 0)
88| Perror("sendto");
89| fprintf(stderr, "-%d->\n", cc);
90| }
91| }
{{suivi| mini-ping | mini-ping | Programmation avancée | Programmation avancée }}

Identifiant d'interface

2006-04-06T12:06:48Z

Bruno Stévant: /* EUI-64 */

{{suivi |Lien-local|Adresses Lien-local|Site-local|Site-local}}

Les types d'adresses global ou lien-local utilisent un identifiant sur 64 bits pour désigner une interface connectée sur un lien. Si cette longueur n'est pas directement imposée par la norme d'adressage d'IPv6 RFC 3513, elle bénéficie d'un fort consensus car elle permet de garantir facilement une unicité sur le lien et par conséquent de faciliter l'auto-configuration des équipements.

Plusieurs techniques ont été élaborées à l'IETF. La plus répandue est basée sur l'utilisation d'une valeur unique par construction comme l'adresse MAC de la machine. Mais l'on peut également choisir une valeur aléatoire pour garantir plus de confidentialité ou au contraire la dériver d'une clé publique pour mieux authentifier l'émétteur du message. La taille de 64 bits permet de réduire à une valeur proche de zéro la probabilité de conflits. Enfin dans certains cas l'affectation manuelle de cette valeur peut se justifier.

Les chapitres suivants décrivent ces différentes méthodes ainsi que leur intérêts et leur défauts.

== Différents types d'identifiants d'interface==
=== EUI-64 ===

L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 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 :

[[image:Fig3-8.png|thumb|right|350px|Figure 3-8 ''identificateur global IEEE EUI-64'']]

* 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. <br>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.
: 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.

[[image:Fig3-9.png|thumb|right|350px|Figure 3-9 ''Identificateur d'interface dérivé d'une EUI-64'']]

* 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>.

[[image:Fig3-10.png|thumb|right|350px|Figure 3-10 ''Transformation d'une adresse MAC en identifiant d'interface'']]

* Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou FDDI), cette adresse est utilisée pour construire des identifiants d'interface sur 64 bits, comme indiqué sur la figure ci-contre.
: A 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 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.
* 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. <br>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.

=== Manuel ===

L'utilisation de l'adresse MAC pour construire l'adresse IP de la machine peut conduire dans certains cas à des problèmes de configuration, en particulier si la machine est un serveur. En effet, s'il l'on change la carte Ethernet de l'équipement (voire l'équipement) l'adresse IPv6 qui en dépend change également.

Le resolveur DNS est le cas le plus flagrant, chaque machine sur le réseau doit posséder dans le fichier <tt>/etc/resolv.conf</tt> l'adresse IPv6, en cas de changement de carte réseau, l'ensemble de machine du domaine devront être reconfigurée manuellement pour prendre en compte le changement d'adresse. Si l'on ne souhaite pas utiliser des protocoles de configuration automatique de type DHCPv6, il est préférable d'attribuer au resolver DNS une adresse manuelle.

=== Valeur aléatoire ===

L'identifiant d'interface tel qu'il a été défini 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.

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.

L'adresse publique globale est conservée, mais ne sera jamais choisie pour initier des communications. Elle permettra par contre d'en recevoir, même si l'anonymat est validé.

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.

Ces identifiants privés ne sont pas incompatibles avec les identifiants publics. Une machine peut attendre des ouvertures de connexions sur ses adresses publiques, par contre initier les connexions en utilisant ses identifiants privés. Il suffit de considérer que les adresses publiques sont dépréciées pour une durée indéterminée.

[[image:Fig3-A.png|thumb|right|350px|''Configuration des interfaces sous Windows'']]

La figure Configuration des interfaces sous Windows illustre cette propriété, en retournant le résultat de la commande <tt>ipconfig</tt>. On peut noter que l'interface du réseau sans-fils possède trois adresses IPv6 (une lien locale et deux globales). Les adresses globales possèdent le même préfixe de 64 octets (<tt>2001:660:7307:6030::/64</tt>). La première adresse globale a le bit <tt>u=0</tt> dans l'identifiant d'interface, il s'agit de celle générée aléatoirement. La deuxième à le bit <tt>u</tt> à <tt>1</tt> et l'on retrouve la séquence <tt>0xFFFE</tt> au milieu de l'identifiant d'interface; cette adresse est dérivée de l'adresse MAC. Sous Windows, par défaut, les adresses aléatoires ont une durée de vie d'une semaine. Par exemple, en utilisant la commande <tt>netsh</tt> :

netsh interface ipv6>'''show address'''
Recherche du statut actif...

Interface 7 : Connexion réseau sans fil

Type adr. État DAD Vie valide Vie préf. Adresse
--------- --------- ---------- ---------- -----------------------------------
Temporaire Préféré 6d21h18m38s 21h15m51s 2001:660:7307:6030:c853:e48b:aafb:c354
Public Préféré 29d23h58m59s 6d23h58m59s 2001:660:7307:6030:204:e2ff:fe5a:9f
Liaison Préféré infinite infinite fe80::204:e2ff:fe5a:9f

=== Cryptographique ===

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.

==Selection du type d'identifiant d'interface==

Si l'on sélectionne correctement le type d'identifiant d'interface, la gestion de l'adressage IPv6 est aussi facile (voire plus simple) qu'en IPv6. Ainsi, il est préférable de donner aux serveurs des identifiants d'inteface construit manuellement. Il sera ainsi beaucoup plus facile de se rappeler de leur adresse. De plus si l'équipement est remplacé et par conséquent que la carte réseau est différente, l'adresse IPv6 restera stable. Pour les clients, il est plus simple d'utiliser l'identifiant d'interface construit à partir de l'adresse MAC.

{{suivi |Lien-local|Adresses Lien-local|Site-local|Site-local}}

Talk:Bibliographie

2006-02-24T10:24:29Z

Bruno Stévant:

Mmmh mais il ne manquerait pas toute la liste des RFC ssur cette page ?? -- BS

Talk:Accès des entreprises et des particuliers à l'Internet IPv6

2006-02-23T14:02:45Z

Bruno Stévant:

Je pense qu'ici il faut différencier les moyens d'accéder à IPv6 avec et sans fournisseur d'accés.

Sans fournisseur on a
* ISATAP, plutôt destiné aux réseaux d'entreprise
* TEREDO, plutôt destiné à des applications chez le particulier

Avec fournisseur d'accès, on donner différents opérateurs en fonction des solutions utilisées :
* Tunnel 6over4 : [https://tb.ipv6.btexact.com/ BTExact], [http://www.sixxs.net SixXs] (?)
* TSP : Hexago, Renater
* Point6 ? :)

Talk:Configuration avec état :DHCPv6

2006-02-13T12:46:58Z

Bruno Stévant:

Ca manque cruellement de Délégation de préfixe. Mais cela ne devrait pas plutôt être traité dans [[Configuration des routeurs]] ? -- [[Utilisateur:Bruno_Stévant|BS]]

== DSTM ==

L'option DSTM est introuvable dans le RFC DHCPv6. Peut etre ce chapitre meriterait une mise a jour ;)
Sinon, d'accord avec BS en ce qui concerne le PD.
BD

== Options DHCPv6 ==

Bonjour, j'ai essayé de remettre a jour les options DHCPv6, je mets ca ici en attente de commentaire avant intégration.
Merci
-- BD

J'ai ajouté les attributs RADIUS définis dans [http://bgp.potaroo.net/ietf/draft-ietf-dhc-v6-relay-radius-01.txt]. Ces options sont valables dans les messages Relay uniquement : peut être devrait-on mieux différencier la sémantique des options en fonction des messages ? -- BS

-> Je suis d'accord... Le systeme de changement de couleur est assez pénible donc du coup j'ai pas eu le courage de reordonner tout ca. On fait quoi ? Server - Client - Relai ?

Il faudrait déjà présenter fonctionnement avec relais (=> nouvelle figure ?) et indiquer pour chaque option dans quelle contexte elle peut être utiliser (=> une collone du tableau en plus ?). On détaillera après la sémantique quand il y en a besoin.

{|
|+'''Options de DHCPv6'''
! Désignation || Définition
|-style="background:silver"
|Association d'Identification pour Adresses Temporaires (IA_TA)|| Liste des adresses IPv6 d'une interface du client.
|-
|Association d'Identification pour Adresses Permanentes (IA_NA) || Liste des adresses IPv6 permanentes d'une interface du client.
|-style="background:silver"
|Adresse de l'IA (IA_ADDR) || Option encapsulée dans une option IA_TA ou IA_NA pour spécifier une des adresses de l'association.
|-
|Requêtes d'options (ORO) ||Liste des informations de configuration demandées par le client.
|-style="background:silver"
|Message relayé || Pour l'encapsulation du message DHCP du client ou du serveur par le relais.
|-
|Authentification || Pour authentification de la source du message DHCP et de la validation de son intégrité.
|-style="background:silver"
|Serveur Unicast || Permet d'autoriser le client a utiliser l'adresse unicast du serveur (spécifiée dans l'option) pour le contacter directement. Ces messages ne peuvent passer par un relais DHCP.
|-
|Identifiant du Client || Identifiant permanent du client (DUID).
|-style="background:silver"
|Identifiant du Serveur || Identifiant permanent du serveur (DUID).
|-
|Préférence || Moyen donné au client de choisir le serveur DHCP. Le serveur sélectionné aura en charge de fournir les paramètres de configuration à ce client.
|-style="background:silver"
|Temps écoulé || Cette option doit être incluse par le client pour indiquer depuis combien de temps il essaye de finaliser l'échange. Permet le déclenchement d'un serveur secondaire si le temps écoulé dépasse une certaine valeur.
|-
|Code d'état || Permet d'ajouter des codes d'état dans les options DHCP. Si cette option est absente, le code par défaut est "Succès".
|-style="background:silver"
|Validation Rapide (Rapid Commit) || Permet au client d'indiquer qu'il peut utiliser la procédure de validation rapide (échange simplifié de messages sans acquittement).
|-
|Classe d'utilisateur || Permet de spécifier la/les classe(s) d'un utilisateur afin de récupérer des informations génériques a ce groupe.
|-style="background:silver"
|Classe de matériel || Permet de spécifier le matériel/OS du client afin d'obtenir des informations spécifiques.
|-
|Identifiant d'Interface || Permet a un relais de connaître l'interface sur laquelle le client a envoyé la requête.
|-style="background:silver"
|Information constructeur || Permet de spécifier le constructeur du matériel afin de réaliser des configurations spécifiques.
|-
|Message de reconfiguration || Utilisé par le serveur dans un message de reconfiguration pour indiquer au client s'il doit répondre par une requête "Renouvellement DHCP" ou "Requete DHCP".
|-style="background:silver"
|Acquittement de reconfiguration || Permet au client d'indiquer au serveur qu'il peut accepter les messages de reconfiguration et au serveur de demander au client d'accepter ces messages ou non.
|-
|Attributs RADIUS (RRAO) || Utilisé par le relais pour fournir au serveur des informations supplémentaires sur le client provenant d'une base RADIUS : (nom de l'utilisateur, préfixes ou pool d'allocation de préfixes IPv6).
|}

Talk:Configuration avec état :DHCPv6

2006-02-13T11:37:49Z

Bruno Stévant: /* Options DHCPv6 */

Ca manque cruellement de Délégation de préfixe. Mais cela ne devrait pas plutôt être traité dans [[Configuration des routeurs]] ? -- [[Utilisateur:Bruno_Stévant|BS]]

== DSTM ==

L'option DSTM est introuvable dans le RFC DHCPv6. Peut etre ce chapitre meriterait une mise a jour ;)
Sinon, d'accord avec BS en ce qui concerne le PD.
BD

== Options DHCPv6 ==

Bonjour, j'ai essayé de remettre a jour les options DHCPv6, je mets ca ici en attente de commentaire avant intégration.
Merci
-- BD

J'ai ajouté les attributs RADIUS définis dans [http://bgp.potaroo.net/ietf/draft-ietf-dhc-v6-relay-radius-01.txt]. Ces options sont valables dans les messages Relay uniquement : peut être devrait-on mieux différencier la sémantique des options en fonction des messages ?

{|
|+'''Options de DHCPv6'''
! Désignation || Définition
|-style="background:silver"
|Association d'Identification pour Adresses Temporaires (IA_TA)|| Liste des adresses IPv6 d'une interface du client.
|-
|Association d'Identification pour Adresses Permanentes (IA_NA) || Liste des adresses IPv6 permanentes d'une interface du client.
|-style="background:silver"
|Adresse de l'IA (IA_ADDR) || Option encapsulée dans une option IA_TA ou IA_NA pour spécifier une des adresses de l'association.
|-
|Requêtes d'options (ORO) ||Liste des informations de configuration demandées par le client.
|-style="background:silver"
|Message relayé || Pour l'encapsulation du message DHCP du client ou du serveur par le relais.
|-
|Authentification || Pour authentification de la source du message DHCP et de la validation de son intégrité.
|-style="background:silver"
|Serveur Unicast || Permet d'autoriser le client a utiliser l'adresse unicast du serveur (spécifiée dans l'option) pour le contacter directement. Ces messages ne peuvent passer par un relais DHCP.
|-
|Identifiant du Client || Identifiant permanent du client (DUID).
|-style="background:silver"
|Identifiant du Serveur || Identifiant permanent du serveur (DUID).
|-
|Préférence || Moyen donné au client de choisir le serveur DHCP. Le serveur sélectionné aura en charge de fournir les paramètres de configuration à ce client.
|-style="background:silver"
|Temps écoulé || Cette option doit être incluse par le client pour indiquer depuis combien de temps il essaye de finaliser l'échange. Permet le déclenchement d'un serveur secondaire si le temps écoulé dépasse une certaine valeur.
|-
|Code d'état || Permet d'ajouter des codes d'état dans les options DHCP. Si cette option est absente, le code par défaut est "Succès".
|-style="background:silver"
|Validation Rapide (Rapid Commit) || Permet au client d'indiquer qu'il peut utiliser la procédure de validation rapide (échange simplifié de messages sans acquittement).
|-
|Classe d'utilisateur || Permet de spécifier la/les classe(s) d'un utilisateur afin de récupérer des informations génériques a ce groupe.
|-style="background:silver"
|Classe de matériel || Permet de spécifier le matériel/OS du client afin d'obtenir des informations spécifiques.
|-
|Identifiant d'Interface || Permet a un relais de connaître l'interface sur laquelle le client a envoyé la requête.
|-style="background:silver"
|Information constructeur || Permet de spécifier le constructeur du matériel afin de réaliser des configurations spécifiques.
|-
|Message de reconfiguration || Utilisé par le serveur dans un message de reconfiguration pour indiquer au client s'il doit répondre par une requête "Renouvellement DHCP" ou "Requete DHCP".
|-style="background:silver"
|Acquittement de reconfiguration || Permet au client d'indiquer au serveur qu'il peut accepter les messages de reconfiguration et au serveur de demander au client d'accepter ces messages ou non.
|-
|Attributs RADIUS (RRAO) || Utilisé par le relais pour fournir au serveur des informations supplémentaires sur le client provenant d'une base RADIUS : (nom de l'utilisateur, préfixes ou pool d'allocation de préfixes IPv6).
|}

Talk:Unicast Global

2006-02-13T09:36:07Z

Bruno Stévant:

Bon, quand est ce qu'on vire ces adresses 6Bone ;)

Main Page

2006-02-10T14:16:14Z

Bruno Stévant:

Checksum au niveau transport

2006-02-09T15:10:53Z

Bruno Stévant:

{{suivi|Exemples d'extensions|Exemples d'extensions|ICMPv6|ICMPv6}}

Parmi les différences existant entre les datagrammes IPv4 et IPv6, il y a la disparition du checksum dans les en-têtes IP. Cette somme de contrôle était utilisée pour vérifier la validité de l'en-tête du paquet traité. En IPv4, il est nécessaire de la vérifier et de l'ajuster lors de chaque retransmission par un routeur, ce qui entraîne une augmentation du temps de traitement du paquet.

Cette somme ne vérifie que l'en-tête IPv4, pas le reste du paquet. Aujourd'hui les supports physiques sont de meilleure qualité et savent détecter les erreurs (par exemple, Ethernet a toujours calculé sa propre somme de contrôle ; PPP, qui a presque partout remplacé SLIP, possède un CRC). L'intérêt de la somme de contrôle a diminué et ce champ a été supprimé de l'en-tête IPv6.

Le checksum sur l'en-tête IPv6 n'existant plus, il faut quand même se prémunir des erreurs de transmission. En particulier, une erreur sur l'adresse de destination va faire router un paquet dans une mauvaise direction. Le destinataire doit donc vérifier que les informations d'en-tête IP sont incorrectes pour éliminer ces paquets. Dans les mises en oeuvre des piles de protocoles Internet, les entités de niveau transport remplissent certains champs du niveau réseau. Il a donc été décidé que tous les protocoles au-dessus d'IPv6 devaient utiliser une somme de contrôle intégrant à la fois les données et les informations de l'en-tête IPv6. La notion de pseudo-en-tête dérive de cette conception. Pour un protocole comme TCP qui possède une somme de contrôle, cela signifie modifier le calcul de cette somme. Pour un protocole comme UDP qui possède une somme de contrôle facultative, cela signifie modifier le calcul de cette somme et le rendre obligatoire.

[[image:CS37.gif]]

IPv6 a unifié la méthode de calcul des différentes sommes de contrôle. Celle-ci est calculée sur l'ensemble formé de la concaténation d'un pseudo-en-tête (cf. Champ du pseudo-en-tête) et du paquet du protocole concerné. L'algorithme de calcul du checksum est celui utilisé en IPv4. Il est très simple à mettre en ?uvre et ne demande pas d'opérations compliquées. Il s'agit de faire la somme en complément à 1 des mots de 16 bits du pseudo-en-tête, de l'en-tête du protocole de transport, et des données, puis de prendre le complément à 1 du résultat.

Il faut noter que les informations contenues dans le pseudo-en-tête ne seront pas émises telles quelles sur le réseau. Le champ "en-tête suivant" du pseudo-en-tête ne reflète pas celui qui sera émis dans les paquets puisque les extensions ne sont pas prises en compte dans le calcul du checksum. Ainsi, si l'extension de routage est mise en oeuvre, l'adresse de la destination est celle du dernier équipement. De même le champ longueur est sur 32 bits pour contenir la valeur de l'option jumbogramme, si celle-ci est présente.

{{suivi|Exemples d'extensions|Exemples d'extensions|ICMPv6|ICMPv6}}

Le multicast IPv6 sur le lien-local

2006-02-08T17:28:03Z

Bruno Stévant:

{{suivi| Adressage multicast | Adressage multicast | Exemples de fonctionnement de MLDv1 | Exemples de fonctionnement de MLDv1}}

==Gestion des abonnements sur le lien-local : MLD==

Pour offrir un service de distribution multicast, deux composants sont nécessaires : un protocole de gestion de groupe multicast et un protocole de construction d'arbre multicast. Le protocole de gestion de groupe multicast réalise la signalisation entre l'hôte et son routeur d'accès à l'Internet. En IPv6, ce protocole est MLD (''Multicast Listener Discovery''). Il est utilisé par un routeur de bordure IPv6 pour découvrir la présence de récepteurs multicast sur ses liens directement attachés, ainsi que les adresses multicast concernées.

MLD est un protocole asymétrique qui spécifie un comportement différent pour les hôtes et les routeurs multicast. Toutefois, pour les adresses multicast sur lesquelles un routeur lui-même écoute, il doit exécuter les deux parties du protocole et répondre à ses propres messages.

Comme MLD est un sous-protocole d'ICMPv6, les messages MLD sont des messages ICMPv6 particuliers. Ils sont envoyés avec :

* une adresse source IPv6 lien-local ;
* le champ "nombre de sauts" fixé à 1 ;
* l'option "IPv6 Router Alert" activée.

Cette dernière option est nécessaire afin de contraindre les routeurs à examiner les messages MLD envoyés à des adresses multicast par lesquelles les routeurs ne sont pas intéressés. La version d'origine du protocole MLD (RFC 2710) (que nous appellerons également MLDv1) présente les mêmes fonctionnalités que le protocole IGMPv2 en IPv4.

Trois types de messages sont utilisés. Leur format est donné sur la figure Format générique d'un message ICMP pour MLD:

[[image:CS104.gif]]

* recensement des récepteurs multicast (type = 130) avec deux sous-types de messages :
* recensement général émis à l'adresse de diffusion générale sur le lien (<tt>FF02::1</tt>)
* recensement spécifique à une adresse multicast, l'adresse de destination est l'adresse multicast du groupe en question
* rapport d'abonnement multicast (type = 131), l'adresse de destination est l'adresse multicast du groupe en question
* résiliation d'abonnement multicast (type = 132), émis à l'adresse du groupe multicast "tous les routeurs du lien local" (<tt>FF02::2</tt>).

Les champs ont la signification suivante :

* type : prend la valeur 130, 131 ou 132.
* code : mis à zéro par l'émetteur et ignoré par les récepteurs
* checksum : celui du protocole ICMPv6 standard, couvrant tout le message MLD auquel s'ajoutent les champs du pseudo-en-tête IPv6
* délai maximal de réponse :
** utilisé seulement dans les messages de recensement. Il exprime le retard maximal autorisé (en millisecondes) pour l'arrivée des rapports d'abonnement
** dans les messages de rapport ou de résiliation d'abonnement ce champ est mis à zéro par l'émetteur et ignoré par les récepteurs
* inutilisé : mis à zéro par l'émetteur et ignoré par les récepteurs
* adresse multicast :
** pour un message de recensement général ce champ est mis à zéro
** pour un message de recensement spécifique il contient l'adresse multicast en question
** pour les messages de rapport et de résiliation d'abonnement, le champ contient l'adresse multicast sur laquelle l'hôte souhaite écouter ou cesser d'écouter

===Messages de recensement et rapports d'abonnement périodiques MLD===

Le routeur envoie régulièrement des messages de recensement général à l'adresse de diffusion générale sur le lien (<tt>FF02::1</tt>). Les hôtes arment un temporisateur pour chaque adresse multicast qui les concerne. Si un temporisateur expire sans que l'hôte ait entendu une réponse d'un de ses voisins concernant la même adresse, il envoie un rapport d'abonnement à l'adresse multicast du groupe. Ce système de temporisateurs permet aux hôtes de surveiller les rapports des autres hôtes sur le lien et d'annuler leurs propres rapports concernant les mêmes adresses. Ainsi la quantité du trafic MLD peut être minimisée.

===Rapports d'abonnements MLD non-sollicités===

Les changements d'état des hôtes sont notifiés par des messages non-sollicités :

* Pour souscrire à une adresse multicast spécifique, un hôte envoie un rapport d'abonnement non-sollicité ;
* Pour cesser d'écouter sur une adresse multicast, l'hôte peut simplement ne plus répondre aux messages de recensement du routeur. S'il est le seul récepteur de cette adresse multicast sur le lien, après un certain temps l'état du routeur concernant cette adresse expire. Le routeur arrêtera de faire suivre les paquets multicast envoyés à l'adresse en question, s'il s'avère que l'hôte était le dernier concerné par l'adresse multicast sur le lien;
* La résiliation rapide est aussi une possibilité offerte par MLDv1. L'hôte envoie un message de résiliation d'abonnement à l'adresse multicast de "tous les routeurs du lien local" (<tt>FF02::2</tt>). Le routeur répond avec un message de recensement spécifique à l'adresse en question. S'il n'y a plus de récepteur pour répondre à ce recensement, le routeur efface l'adresse multicast de sa table de routage.

Il est possible d'avoir plusieurs routeurs multicast sur le même lien local. Dans ce cas un mécanisme d'élection est utilisé pour choisir le routeur recenseur. Celui-ci sera le seul responsable pour l'envoi des messages de recensement.

{{suivi| Adressage multicast | Adressage multicast | Exemples de fonctionnement de MLDv1 | Exemples de fonctionnement de MLDv1}}