Peut-être va-t-on enfin savoir à quoi peuvent servir ces 20 bits de l’en-tête IPv6. Pour faire simple, 3 RFC sortent sur le sujet suite au dernier meeting IETF:
- RFC6436: critique du modèle actuel (ce travail fait suite à un état des lieux publié en juin dernier dans le RFC6294)
- RFC6437: mise à jour des anciennes spécifications (rend obsolète le RFC3697)
- RFC6438: un exemple d’usage du flow label qui se base sur les nouvelles specs
NDLA: Peut-être aurais-je du faire pareil et poster 3 articles sur le blog pour gonfler mes stats de publication? 🙂
Essayons d’y voir plus clair. Tout d’abord, qu’est-ce qui ne va pas avec les specs initiales? Les 3 règles de base définies dans le RFC3697 semblent ne permettre aucun usage du flow label:
- Le flow label ne devait pas être modifié entre source et récepteur. La première difficulté est qu’on n’avait pas moyen de vérifier que cette règle était respectée (il n’y a pas de checksum pour le header IPv6). La seconde est qu’il n’est du coup pas possible d’utiliser le flow label si le host ne le fait pas: il est par exemple impossible sur un réseau de mettre en place une gestion des ECMP basé sur le flow label puisqu’on n’a jamais la certitude que le host source positionnera le bon flow label. Troisième difficulté: les gens de la sécu n’aiment pas trop l’idée de ne pas avoir le droit de dépendre de ce champ et de ne pas avoir le droit de le modifier…
- les noeuds ne doivent pas faire d’analyse sur le flow label IPv6 (qui ne doit pas avoir de signification). Ici on n’autorise donc que les modèles sans états (cad ceux où les noeuds du réseau ne communiquent pas entre eux sur une éventuelle signification) et on s’empêche toute utilisation dans lesquelles les noeuds se mettraient d’accord sur l’utilisation de ce champ.
- la performance ne doit pas dépendre de ce seul flow label. A priori pas de problème avec cette règle mais il faut bien faire attention à bien lire la règle: il est possible d’utiliser conjointement ce champ avec un autre pour en tirer globalement une décision sur la performance à appliquer
Maintenant regardons ce qui change dans les nouvelles specifications.
- Le flow label doit être choisi pour qu’il y ait une variabilité maximale (ce champ ne doit pas pouvoir être deviné ou rejoué), une distribution uniforme doit donc être adoptée. Différentes solutions sont proposées pour permettre de définir ce champ sans nécessiter la création d’états. On peut se baser sur le 5-tuple IP source, IP destination, protocole, port source, port destination; ou bien sur un 2-tuple IP source, IP destination.
- Le flow label ne peut servir seul à élaborer une quelconque règle puisque ce champ n’est contrôlé par aucun checksum. Il faut par exemple combiner le flow label à d’autres champs (par exemple les adresses source et destination) pour garder une variabilité même si tous les paquets sont reçus avec la même valeur de flow label.
- Un flow label de 0 (zero) signifie qu’il n’a pas été positionné.
- Un routeur (par exemple le 1er routeur) peut maintenant positionner un flow label si celui reçu était nul. Les conditions pour l’attribuer (distribution uniforme) et les algorithmes ne sont pas différentes de celles qui définissent le positionnement par le host source.
- Un flow label non nul ne doit pas être modifié, sauf absolue nécessité sécuritaire. Dans ce dernier cas un firewall pourrait repositionner un flow label à 0 (toute autre modification est interdite)
- Toute méthode de calcul du flow label avec état devrait tout de même suivre les règles de base décrites ci-dessus (le RFC recommande de rester sur une solution sans états)
En faisant ces petites modifications, les auteurs espèrent une utilisation du flow label IPv6. Notamment dans le RFC 3648, il rappellent que pour la gestion des LAG ou ECMP, un algorithme de hashing basé sur le flow label et les adresses source et destination permettrait une meilleure répartition des flux sur les n liens que si l’on ne se base que sur les seules adresses. Les auteurs rappellent qu’en raison de la présence des extensions IPv6 (en-tête de taille variable inhérent à IPv6), l’extraction des ports source et destination est plus difficile en IPv6 qu’en IPv4 sur un routeur de coeur. Le flow label est donc bienvenu! Les auteurs prennent comme exemple les tunnels: en cas d’ECMP ou LAG, le flow label peut servir à répartir intelligemment le trafic entre les TEP (Tunnel End Points) sur les différents liens sans risquer de nuire aux flux encapsulés. A ce titre on indique comment le TEP source peut définir le flow label à partir des du 2-tuple IP source / IP destination ou 5-tuple IPsource / IP destination / protocole / port source / port destination du paquet encapsulé.
Authors
