TdMbis

From Livre IPv6

Revision as of 15:53, 18 December 2009 by Mcoic (Talk | contribs) (Routage)

Table des matières

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

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

Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante:

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

Glossaire (TOUS LES EDITEURS)

Préambule

Introduction

Adressage (Laurent Toutain)

Protocoles réseau et transport (Laurent Toutain)

Configuration automatique et contrôle (Laurent Toutain)

Nommage (Mohsen Souissi)

Supports de transmission (Laurent Toutain)

Routage

Multicast

Format des adresses multicast IPv6

Généralités

Cette section décrit le système d'adressage multicast IPv6. La figure Structure de l'adresse IPv6 Multicast donne le format de l'adresse IPv6 de multicast décrite dans le RFC 3513.

CS99.gif

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

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

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

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

  • 1 - node-local
  • 2 - link-local
  • 3 - subnet-local
  • 4 - admin-local
  • 5 - site-local
  • 8 - organisation-local
  • E - global
  • Les portées 0 et F sont réservées.

Adresses multicast IPv6 permanentes

Une adresse multicast IPv6 avec le bit T du champ drapeaux à 0 correspond à une adresse multicast permanente, allouée par l'IANA.

CS100.gif

Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe FF00::/12.

Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :

  • des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP,...) et
  • des adresses correspondant d'avantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision. Le RFC 3307 définit des procédures pour l'allocation des adresses multicast permanentes. Celles-ci seront décrites par la suite.

Adresses temporaires

Les adresses temporaires sont des adresses multicast IPv6 dont le bit T est positionné à 1. Il existe plusieurs types d'adresses temporaires :

  • générales : Ce sont des adresses avec tous les bits du champ flag à 0 sauf le bit T positionné à 1. Il n'y a pas de recommandations pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.
  • dérivées d'un préfixe unicast IPv6. Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast :

CS101.gif

    • res (reserved) : tous les bits de ce champ doivent être positionnés à 0.
    • Plen (prefix length) : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.
    • prefix : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.
    • group-ID : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre Identifiant de groupe.
Par exemple, une adresse multicast peut être dérivée à partir du préfixe de RENATER (2001:660::/32). Le champ prefix prend la valeur 2001:0660:0000:0000 et le champ Plen, la valeur 0x20 (32 en décimal). Les adresses multicast IPv6 à choisir seront de type FF3X:20:2001:660::aabb:ccdd (aabb:ccdd étant le group-ID choisi dans l'exemple).
Cette méthode permet la création potentielle de 232 adresses par préfixe.
  • les adresses multicast "Embedded-RP" voir le RFC 3618 définit une méthode pour inclure l'adresse du RP (Point de Rendez-Vous servant à la construction de l'arbre multicast) dans l'adresse multicast IPv6. Le schéma Structure d'une adresss IPv6 Multicast "embedded RP" montre la structure d'une telle adresse, aussi appelée adresse "embedded-RP" :

CS102.gif

Ainsi pour un point de rendez-vous qui possède l'adresse 2001:660:3307:125::3, une adresse multicast correspondante peut être dérivée de la façon suivante :
    • res (Reservé) : Les 4 bits de ce champ sont positionnés à 0.
    • RPad : Ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.
    • Plen (Longueur du préfixe) : Ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de 0x40 (soit 64 en décimal),
    • prefix (Préfixe) : Ce champ contient le préfixe réseau du RP. Ici, cette valeur est 2001:660:3007:125
    • group-ID : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre Identifiant de groupe.
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme FF7X:340:2001:660:3007:125:aabb:ccdd (aabb:ccdd étant le group-ID choisi dans cet exemple).
  • Les adresses SSM (Source Specific Multicast) sont décrites également dans le RFC 3306. Si le préfixe FF3X::/32 a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe FF3X::/96 doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs Plen et prefix sont positionnés à 0 (cf. figure Structure des adresses IPv6 Multicast SSM).

CS103.gif

Le tableau Récapitulatif des types d'adresses multicast définis récapitule les préfixes associés aux differents types d'adresses multicast décrit précédement.

Récapitulatif des types d'adresses multicast définis
Préfixe Usage
FF0X::/16 Adresses IPv6 multicast permanentes
FF1X::/16 Adresses IPv6 multicast temporaires générales
FF3X::/16 Adresses multicast dérivées d'un préfix unicast (temporaires)
FF3X::/96 Adresses SSM (temporaires)
FF7X::/16 Adresses IPv6 multicast "Embedded-RP" (temporaires)

Identifiant de groupe

Le RFC 3307 décrit des procédures de création d'un identifiant de groupe (Group-ID) et le RFC 3513 fixe la taille du champ Group-ID à 112 bits. Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2 : les 32 derniers bits de l'adresse multicast IPv6 sont ajoutés au préfixe MAC 33-33.

Par exemple, l'adresse FF0E:30:2001:660:3001:4002:AE45:2C56 correspondra à l'adresse MAC 33-33-AE-45-2C-56. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ group-ID à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.

Le RFC 3307 définit aussi les adresses IPv6 multicast et identifiants de groupe qui seront gérés par l'IANA, où réservés pour des allocations dynamiques.

Récapitulatif des usages des identifiants de groupe
Description Valeur minimale de l'identifiant de groupe Valeur maximale de l'identifiant de groupe
Adresse multicast permanente C'est une adresse allouée par l'organisme IANA. Les bits P et T doivent être initialisés à zéro. 0x00000001 0x3FFFFFFF
Identifiant de groupe permanent Le but de ces identifiants de groupe est de pouvoir identifier un service donné dans un réseau. Ces services sont définis par des Group-ID alloués par l'IANA et devraient être utilisées pour des adresses IPv6 multicast dérivées d'un préfixe unicast (RFC 3306). Avec cette méthode, il est théoriquement possible d'atteindre un service donné dans n'importe quel réseau. 0x40000000 0x7FFFFFFF
Adresse multicast dynamique Les adresses multicast allouées dynamiquement doivent avoir un group-ID compris entre 0x80000000 et 0xFFFFFFFF. Ces adresses ont le bit T du champ drapeaux positionné à 1. 0x80000000 0xFFFFFFFF
Multicast Table des matières Le multicast IPv6 sur le lien-local

Le multicast IPv6 sur le lien-local

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:

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 (FF02::1)
  • 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" (FF02::2).

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 (FF02::1). 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" (FF02::2). 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.

Adressage multicast Table des matières Exemples de fonctionnement de MLDv1


Gestion des abonnements sur le lien-local : MLD version 2

La nouvelle version du protocole de gestion de groupe multicast, MLDv2 est décrite dans le RFC 3810. Elle implante les fonctionnalités du protocole IGMPv3 défini pour IPv4, la plus importante étant l'introduction du filtrage des sources. Un hôte peut désormais spécifier les sources qu'il veut ou qu'il ne veut pas écouter pour une adresse multicast donnée. Cette information peut être utilisée par les protocoles de routage multicast afin d'éviter l'acheminement des paquets multicast provenant de certaines sources vers des liens où il n'y a pas de récepteur intéressé.

Pour être en mesure de supporter les fonctionnalités de MLDv2, l'API de l'hôte doit permettre l'opération suivante (ou un équivalent logique de celle-ci) :

EcouteIPv6Multicast (socket, interface,

adresse multicast IPv6, mode de filtrage,
liste de sources)

Par cet appel, une application demande, pour une certaine adresse multicast, la réception de paquets sur une certaine interface, en tenant compte du mode de filtrage et de la liste des sources spécifiées. Le mode de filtrage peut être soit INCLUDE, soit EXCLUDE :

   * En mode INCLUDE, la réception des paquets envoyés à l'adresse multicast spécifiée est demandée seulement pour ceux en provenance des sources présentes dans la liste qui suit
   * En mode EXCLUDE, la réception des paquets est demandée pour toutes les sources, à l'exception de celles spécifiées dans la liste de sources 

Il existe deux types de messages MLDv2 :

   * recensement des récepteurs multicast (type=130)
   * rapport d'abonnement multicast version 2 (type=143) 

Pour garder l'interopérabilité avec la version précédente de MLD, les messages de rapport d'abonnement multicast version 1 et de résiliation d'abonnement multicast sont également supportés.

Messages de recensement MLDv2

Un message de recensement des récepteurs en MLDv2 est donné sur la figure Format d'un message de recensement MLDv2. Les champs ont la signification suivante :

CS105.gif

  • type : le même type qu'en MLDv1
  • code : mis à zéro par l'émetteur et ignoré par les récepteurs
  • checksum : calculé de la même façon que pour la version précédente du protocole
  • délai max. de réponse : utilisé pour calculer le délai maximal de réponse durant lequel le récepteur doit envoyer éventuellement son rapport d'abonnement
  • inutilisé : mis à zéro par l'émetteur et ignoré par les récepteurs,
  • adresse multicast,
  • réservé : mis à zéro par l'émetteur et ignoré par les récepteurs,
  • drapeau S : indique aux routeurs multicast qui reçoivent ce message s'ils doivent ou pas supprimer la mise à jour des temporisateurs, effectuée normalement au moment de la réception d'un message de recensement,
  • QRV : contient la variable de robustesse utilisée par le recenseur (le nombre de fois qu'un récepteur envoie un rapport pour être robuste aux pertes dans le réseau),
  • QQIC : code utilisé pour calculer l'intervalle de recensement,
  • nombre de sources,
  • adresse de la source [N], vecteur contenant la liste éventuelle des sources.

Trois types de messages de recensement de récepteurs multicast sont utilisés :

  • recensement général envoyé par un routeur multicast afin de découvrir les adresses multicast pour lesquelles il y a des récepteurs sur ses liens directs. Dans un tel message les champs "adresse multicast" et "nombre de sources" sont mis à zéro
  • recensement spécifique à une adresse multicast envoyé par un routeur multicast afin de découvrir l'existence de récepteurs pour une adresse multicast spécifique. Le champ "adresse multicast" contient l'adresse en question, tandis que le champ "nombre de sources" est mis à zéro
  • recensement spécifique à une adresse multicast et à une source envoyé par un routeur multicast afin de découvrir l'existence de récepteurs pour une adresse multicast et une source spécifiques. Le champ "adresse multicast" contient l'adresse en question, tandis que les champs "adresse source [i]" forment un vecteur de N adresses unicast (valeur spécifiée dans le champ "nombre de sources").

Les messages de recensement général sont envoyés à l'adresse de diffusion générale sur le lien (FF02::1). Les autres messages de recensement sont envoyés à l'adresse multicast spécifiée dans l'en-tête MLDv2.

Rapports d'abonnement MLDv2

Un rapport d'abonnement multicast en MLDv2 est donné sur la figure Format d'un message de rapport d'abonnement MLDv2. Les champs ont la signification suivante :

CS106.gif

  • type, type=143
  • réservés, mis à zéro par l'émetteur et ignorés par les récepteurs
  • checksum, calculé de la même façon que pour la version précédente du protocole
  • nombre d'enregistrements d'adresse multicast
  • enregistrement d'adresse multicast : chaque enregistrement d'adresse multicast a la forme donnée sur la figure Format d'un message de recensement MLDv2 : Les champs ont la signification suivante :

CS107.gif

    • type d'enregistrement : plusieurs types d'enregistrements d'adresse multicast peuvent être inclus dans un rapport d'abonnement :
un "enregistrement d'état actuel" est envoyé par un hôte en réponse à un message de recensement. Il décrit l'état de l'hôte concernant une adresse multicast spécifique .Le champ "type d'enregistrement" peut dans ce cas avoir les valeurs MODE_IS_INCLUDE ou MODE_IS_EXCLUDE,
un "enregistrement de changement de mode de filtrage" est envoyé par un hôte chaque fois qu'un appel EcouteIPv6Multicast modifie son mode de filtrage pour une adresse multicast précise. Le champ "type d'enregistrement" peut dans ce cas avoir les valeurs CHANGE_TO_INCLUDE_MODE ou CHANGE_TO_EXCLUDE_MODE,
un "enregistrement de changement de la liste des sources" est envoyé par un hôte quand un appel EcouteIPv6Multicast modifie la liste des sources qu'il souhaite ou ne souhaite pas écouter pour une adresse multicast précise. Le champ "type d'enregistrement" peut dans ce cas avoir les valeurs ALLOW_NEW_SOURCES ou BLOCK_OLD_SOURCES.
    • LDAux contient la longueur du champ données supplémentaires
  • adresse multicast
  • nombre de sources
  • adresse source [i], vecteur contenant la liste des sources qui doivent être désormais autorisées ou bloquées
  • données supplémentaires, si elles sont présentes, peuvent contenir des informations supplémentaires concernant l'enregistrement d'adresse multicast en question.

Les rapports d'abonnement sont envoyés par les hôtes à l'adresse "tous les routeurs MLDv2" (ff02::16). Ainsi les récepteurs ne reçoivent pas les rapports des autres, chacun étant obligé d'envoyer son propre rapport. Le mécanisme d'économie d'émission des rapports du protocole MLDv1 n'est donc plus utilisé. Le risque de surcharge du routeur à cause du trop grand nombre de rapports reçus est toutefois évité en fixant des temporisateurs avec des valeurs différentes pour chaque rapport.

Fonctionnement de MLDv2

Comme dans le cas du MLDv1, s'il existe plusieurs routeurs multicast sur le même lien local, un seul routeur recenseur va être désigné à l'aide d'un mécanisme spécifique. Le recenseur envoie régulièrement des messages de recensement général auxquels les récepteurs répondent avec des rapports d'abonnement contenant des enregistrements d'état actuel.

Chaque hôte, ainsi que chaque routeur, gardent un état contenant le mode de filtrage et une liste des sources pour chaque adresse multicast. Dans le cas d'un hôte ce sont les adresses multicast sur lesquelles il écoute. Dans le cas d'un routeur ce sont les adresses multicast que ses récepteurs écoutent. Une application sur une machine hôte demande la modification du mode de filtrage ou de la liste des sources pour une adresse multicast précise à travers d'un appel EcouteIPv6Multicast. L'hôte inclut par conséquent ces modifications dans un rapport d'abonnement non-sollicité. Ce rapport contient des enregistrements de changement de mode de filtrage ou de la liste des sources, en conformité avec les changements qui ont eu lieu dans l'état interne de l'hôte.

Au moment de la réception des changements communiqués, le routeur met à jour son état pour l'adresse multicast concernée. Si, suite à ces changements, il constate qu'une certaine source ne doit plus être acceptée, le routeur envoie un message de recensement spécifique pour cette source, afin de vérifier l'existence d'éventuels récepteurs qui souhaitent toujours l'écouter. Un temporisateur est déclenché, et s'il expire sans que le routeur ait reçu un rapport d'abonnement concernant la source, celle-ci est éliminée de l'état local du routeur. Si le routeur détecte que plus aucune source n'est sollicitée pour une certaine adresse, il envoie un message de recensement spécifique pour cette adresse. Si des rapports d'abonnement concernant l'adresse en question ne sont pas reçus en temps dû, l'adresse est effacée de l'état du routeur.

Exemples de fonctionnement de MLDv1 Table des matières Exemples de fonctionnement de MLDv2


Exemples de fonctionnement de MLDv2 (page à reprendre avec les exemples

Sécurité

Mobilité dans IPv6 (Thierry Ernst)

Intégration d'IPv6 et des applications (Bruno Stévant)

Programmation d'applications (Etienne Dublé)

Supervision (Jean-Jacques Broussat)

Historique de la standardisation d’IPv6

Bases whois

Bibliographie

Personal tools