Difference between revisions of "MOOC:Compagnon Act21-s7"

From Livre IPv6

Revision as of 08:34, 19 October 2015

Introduction Séquence 2

Le protocole IP a pour objectif de faciliter la transmission de l’information d’un point à un autre du réseau.

IP est basé sur le modèle datagramme : ce qui signifie que chaque paquet dispose des éléments nécessaires et suffisants au traitement par les équipements indépendamment des paquets traités précédemment.
IP est le langage commun de tous les équipements de l’Internet, sans besoin de traduction en cours d’acheminement de l'information. IP établit le principe du bout-en-bout : aucun équipement intermédiaire ne perturbe l’information transmise, seuls l’émetteur et le destinataire de l’information sont concernés et actifs.
La taille des adresses IP source et destination est fixe : ce qui optimise les traitements nécessaires à la transmission dans le réseau.
L’expérience internet a insufflé et démontré une démultiplication des besoins, et des usages. Il faut désormais répondre aux besoins de communication variés de tous les individus répartis sur la planète, qu’ils soient sédentaires ou en mobilité. Les objets communicants se démultiplient aussi bien en réseau domestique, en entreprise, dans l’industrie, les transports, le milieu médical.
Il y a quarante ans, le protocole IPv4 a défini des adresses sur 32 bits, mais 4,3 milliards d’adresses s’avèrent aujourd’hui insuffisantes pour les nouveaux usages d'Internet. Tandis que les supports de transmission et les équipements se sont améliorés, le protocole IPv4 a gardé la trace de fonctionnalités historiques nécessaires dans les années 80/90 mais qui n’ont plus cours aujourd'hui.
Le protocole IPv6 arrive à temps, c’est un retour aux principes qui ont fait le succès d'IP, garantissant efficacité, résilience et des perspectives d’évolution.
Dans la première séquence vous avez découvert une capacité d’adressage exceptionnelle, dans cette 2° séquence vous allez vous concentrer sur les mécanismes protocolaires. Le fil rouge est l’optimisation du traitement des paquets dans tous les équipements intermédiaires tels que les routeurs, commutateurs de niveau 3, pare-feux. Aux extrémités on retrouve les équipements terminaux tels que stations et serveurs, elles sont responsables de la gestion des en-têtes IP.

Dans cette deuxième séquence du Mooc IPv6 vous aborderez les différents aspects du protocole à travers 5 activités pédagogiques :

A21: Tout d’abord, vous allez passer en revue le format de l’en-tête des paquets IPv6,
A22.Ensuite, vous seront exposé les mécanismes d’encapsulation,
A23: Puis, vous aborderez les principes de routage,
A24: Ensuite, vous décomposerez les extensions de l’en-tête IP à travers des exemples,
A25: Enfin les points essentiels sur des tailles de paquets vous seront exposé ;

Après avoir approfondi tous ces aspects protocolaires

A26: Vous pourrez expérimenter IPv6 à travers dans une première séquence de Travaux Pratiques, vous profiterez d’une machine virtuelle intégrant un simulateur réseau très réaliste qui vous permettra de tester, observer et pratiquer, sans déstabiliser la configuration de votre machine.

Séquence 2

Introduction Activité 21

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 d’une quarantaine d’années 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 r¬outeur en raison entre autres 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 étant 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 la mise en tunnel 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. Pour les réseaux ne le permettant pas, une couche d'adaptation (comme avec les couches d'adaptation AAL5 d'ATM) ou 6LoWPAN avec les réseaux de capteurs (comme IEEE 802.15.4) devra être mise en œuvre 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 PMTU (Path MTU) évitent d'avoir recours à la fragmentation. Si celle-ci s'avère nécessaire, une extension est prévue.

L'idée est de retirer du cœur de réseau les traitements compliqués. Les routeurs ne font que retransmettre les paquets vers la destination, les autres traitements (fragmentation, ...) seront faits par l'émetteur du paquet.

Format de l'en-tête IPv6

Format d'un datagramme IPv6

Format de l'en-tête

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

Valeurs des champs de l'entête

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. Le numéro de version 5 avait déjà été attribué au protocole Stream qui finalement n'a pas eu le succès attendu (RFC 1190, RFC 1819).

Classe de trafic

Le premier mot de 32 bits étant exclu du calcul du checksum avec les pseudo-en-têtes, il est plus facile de le faire évoluer. Dans la version standardisée par le RFC 2460 un champ classe de trafic sur 8 bits permet la différenciation de services conformément aux spécifications du RFC 2474.

Le champ classe de trafic est aussi appelé dans les paquets IPv4 octet DiffServ (DS), il prend la place du champ ToS, initialement défini dans la spécification d'IPv4 (cf. figure Format de l'octet classe de trafic). Le champ DS est découpé en deux parties. Le sous-champ DSCP (DiffServ Code Point) contient les valeurs des différents comportements. Les deux derniers bits du champ servent les routeurs pour indiquer un risque de congestion en combinaison avec l'algorithme RED (Random Early Detection).

Format de l'octet classe de trafic

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

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

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

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

Format du champ DSCP

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

Assured Forwarding : Ce comportement définit quatre classes de services et trois priorités suivant que l'utilisateur respecte son contrat, le dépasse légèrement ou est largement en dehors. Les classes sont donc choisies par l'utilisateur et restent les mêmes tout au long du trajet dans le réseau.

La priorité, par contre, peut être modifiée dans le réseau par les opérateurs en fonction du respect ou non des contrats.Par exemple pour la classe AF n°2 on dispose des 3 priorités suivantes : AF21, AF22, AF23, plus le chiffre est élevé, plus la priorité est faible, c'est à dire qu'en cas de saturation de cette classe de service, les paquets AF23 seront écartés avant AF22, puis AF21.

Expedited Forwarding: Ce comportement est comparable à un circuit à débit constant réservé dans le réseau. Le trafic est mis en forme à l'entrée du réseau, en retardant l'émission des paquets qui sont hors contrat. En plus de ces comportements, l'octet DS a gardé, pour des raisons de compatibilité avec les équipements existants, les valeurs du bit ToS qui étaient le plus fréquemment utilisées. La valeur est 0xEF (1011 1000 en binaire, et en tenant compte des 6 bits de poids forts : 46 en décimal).
Voice Admit: cette autre valeur a été par la suite proposée dans le RFC 5865 pour affiner le traitement de flux temps réels de différentes natures (Voix, Video, Signalisation Temps réel…). Et une autre particularité, la valeur 0xE0 (1110 0000 en binaire, et en tenant compte des 6 bits de poids forts : 56 en décimal) correspond à la classe de contrôle du réseau (Network Control). Elle est utilisée dans des mises en oeuvre d'IPv6 pour l'émission de certains paquets ICMPv6.

Identificateur de flux

Ce champ contient un numéro unique choisi par la source, qui a pour but de faciliter le travail des routeurs et la mise en oeuvre des fonctions de qualité de service comme RSVP. Cet indicateur peut être considéré comme une marque à un contexte dans le routeur. Le routeur peut alors faire un traitement particulier : choix d'une route, traitement en "temps-réel" de l'information.

Avec IPv4, certains routeurs, pour optimiser le traitement, se basent sur les valeurs de cinq champs pour construire un contexte : adresses de la source et de destination, numéros de port de la source et de destination et protocole. Ce contexte sert à router plus rapidement les paquets puisqu'il évite de consulter les tables de routage pour chaque paquet. Ce contexte est détruit après une période d'inactivité.

Avec IPv6, cette technique est officialisée. Le champ identificateur de flux peut être rempli avec une valeur aléatoire qui servira à référencer le contexte. La source gardera cette valeur pour tous les paquets qu'elle émettra pour cette application et cette destination. Le traitement est optimisé puisque le routeur n'a plus à consulter cinq champs pour déterminer l'appartenance d'un paquet. De plus si une extension de confidentialité est utilisée, les informations concernant les numéros de port sont masquées aux routeurs intermédiaires.

L'utilisation de ce champ a été rendue confuse car Cisco dans le cadre du Tag Switching a proposé de l'utiliser pour augmenter la vitesse de commutation des paquets. Cette proposition consiste à ne garantir l'unicité de l'identificateur de flux que sur un lien. Le routeur possède dans sa mémoire une table de correspondance qui permet, en fonction du lien d'arrivée et du numéro d'identificateur de flux, de déterminer le lien de sortie et la nouvelle valeur de l'identificateur. Cette proposition se rapproche énormément des techniques utilisées dans les circuits virtuels (ATM, Frame Relay, X.25...).

Le groupe de travail MPLS (Multi Protocol Label Switching) a intégré les travaux sur le Tag Switching et a précisé la manière dont la commutation des paquets pourra être faite. L'identificateur de flux d'IPv6 n'est plus utilisé, mais un en-tête spécifique est introduit entre l'encapsulation de niveau 2 et celle de niveau 3. L'identificateur de flux n'a plus à être modifié en cours de transmission. Cette évolution clarifie l'utilisation du protocole RSVP (Reservation Protocol) qui peut se baser sur cette valeur, identique tout au long du chemin, pour identifier un flux.

En fait, l'utilisation de l'étiquette de flux est très floue, les micro-flux, c'est-à-dire de flux applicatifs, ne sont pas vus dans le coeur du réseau pour des raisons de scalabilité, de plus MPLS a repris la notion de routage spécifique en fonction d'une étiquette. Pour l'instant ce champ peut être vu comme réservé et son utilisation pourra être mieux spécifiée dans le futur.

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

Format de l'octet 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. 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. 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.

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

Adresses Source et Destination

Traitées précédemment dans la séquence 1.

Extensions ou couches de niveau supérieur

Enchaînement d'extensions IPv6

Cette figure "Enchaînement d'extensions" montre la souplesse avec laquelle plusieurs extensions peuvent être chaînées. Chaque extension contient dans son en-tête un champ en-tête suivant et longueur. Le premier paquet ne contient pas d'extension, le champ en-tête suivant pointe sur TCP. Le second paquet contient une extension de routage qui pointe sur TCP. Dans le dernier paquet, une extension de fragmentation est ajoutée après celle de routage.

Si cet enchaînement d'extension offre beaucoup plus de souplesse que les options d'IPv4, il rend difficile la lecture des numéros de port, il faut en effet lire tout l'enchaînement d'extension pour arriver au protocole de niveau 4. Ceci a servi de justification au l'identificateur de flux qui permettait de refléter au niveau 3 un flux particulier et évitait de dérouler l'enchaînement. Bien entendu, les pare-feux devront vérifier les numéros de ports.

Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6).

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

Nous reviendrons plus sur les détails des extensions dans l’activité 24.

Ressources supplémenatires

Vous pouvez approfondir vos connaissances en consultant les liens suivants :

Retrieved from "http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act21-s7&oldid=9089"

Revision as of 09:33, 15 October 2015 (view source) Jprioual (Talk \| contribs) ← Older edit		Revision as of 08:34, 19 October 2015 (view source) Jprioual (Talk \| contribs) Newer edit →
Line 1:		Line 1:
−		+	__NOTOC__
	== Introduction Séquence 2==		== Introduction Séquence 2==

Association G6