6. Indices de zone
Parce que la même adresse non globale peut être utilisée dans plus d'une zone de la même portée (par exemple, l'utilisation de l'adresse locale au lien fe80::1 dans deux liens physiques séparés) et qu'un nœud peut avoir des interfaces attachées à différentes zones de la même portée (par exemple, un routeur a normalement plusieurs interfaces attachées à différents liens), un nœud nécessite un moyen interne d'identifier à quelle zone une adresse non globale appartient. Ceci est réalisé en assignant, au sein du nœud, un "indice de zone" (zone index) distinct à chaque zone de la même portée à laquelle ce nœud est attaché, et en permettant que tous les usages internes d'une adresse soient qualifiés par un indice de zone.
L'assignation des indices de zone est illustrée dans l'exemple de la figure ci-dessous:
---------------------------------------------------------------
| a node |
| |
| |
| |
| |
| |
| |
| /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ |
| |
| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
---------------------------------------------------------------
: | | | |
: | | | |
: | | | |
(imaginary ================= a point- a
loopback an Ethernet to-point tunnel
link) link)
Figure 1: Zone Indices Example
Ce nœud d'exemple a cinq interfaces:
-
Une interface de bouclage vers le lien de bouclage imaginaire (un lien fantôme qui ne mène nulle part).
-
Deux interfaces au même lien Ethernet.
-
Une interface vers un lien point-à-point.
-
Une interface tunnel (par exemple, le point de terminaison abstrait d'un tunnel IPv6-sur-IPv6 [8], présumément établi sur l'un ou l'autre du lien Ethernet ou du lien point-à-point).
Il est ainsi attaché à cinq zones locales à l'interface, identifiées par les indices d'interface 1 à 5.
Parce que les deux interfaces Ethernet sont attachées au même lien, le nœud n'est attaché qu'à quatre zones locales au lien, identifiées par les indices de lien 1 à 4. Notez également que même si l'interface tunnel est établie sur l'Ethernet, le lien tunnel reçoit son propre indice de lien, qui est différent de l'indice de la zone du lien Ethernet.
Chaque indice de zone d'une portée particulière devrait contenir suffisamment d'informations pour indiquer la portée, de sorte que tous les indices de toutes les portées sont uniques au sein du nœud et que les indices de zone eux-mêmes peuvent être utilisés à un objectif dédié. L'utilisation de l'indice pour identifier une entrée dans la Base d'informations de gestion (MIB - Management Information Base) est un exemple d'objectif dédié. La représentation réelle pour encoder la portée dépend de l'implémentation et sort du cadre de ce document. Au sein de ce document, les indices sont simplement représentés dans un format tel que "indice de lien 2" pour la lisibilité.
Les indices de zone sont strictement locaux au nœud. Par exemple, le nœud à l'autre extrémité du lien point-à-point peut bien utiliser des valeurs d'indice d'interface et de lien entièrement différentes pour ce lien.
Une implémentation devrait également supporter le concept d'une zone "par défaut" (default zone) pour chaque portée. Et, lorsqu'elle est supportée, la valeur d'indice zéro à chaque portée DEVRAIT être réservée pour signifier "utiliser la zone par défaut". Contrairement aux autres indices de zone, l'indice par défaut ne contient pas de portée, et la portée est déterminée par l'adresse que l'indice par défaut accompagne. Une implémentation peut également définir une zone par défaut séparée pour chaque portée. Ces indices par défaut peuvent également être utilisés comme qualificateur de zone pour une adresse pour laquelle le nœud n'est attaché qu'à une seule zone; par exemple, lors de l'utilisation d'adresses globales.
Actuellement, il n'y a pas de moyen pour un nœud de déterminer automatiquement quelles interfaces lui appartiennent aux mêmes zones; par exemple, le même lien ou la même zone de portée de multidiffusion plus grande que l'interface. À l'avenir, des protocoles peuvent être développés pour déterminer cette information. En l'absence de tels protocoles, une implémentation doit fournir un moyen d'assignation et/ou de réassignation manuelle des indices de zone. De plus, pour éviter d'effectuer une configuration manuelle dans la plupart des cas, une implémentation devrait, par défaut, initialement assigner les indices de zone uniquement comme suit:
-
Un indice d'interface unique pour chaque interface.
-
Un indice de lien unique pour chaque interface.
Ensuite, une configuration manuelle serait nécessaire uniquement pour les cas moins courants de nœuds avec plusieurs interfaces à un seul lien ou de ceux avec des interfaces à des zones de portées différentes (réservées à la multidiffusion).
Ainsi, les assignations d'indice de zone par défaut pour le nœud d'exemple de la Figure 1 seraient comme illustré à la Figure 2, ci-dessous. Une configuration manuelle serait ensuite requise pour, par exemple, assigner le même indice de lien aux deux interfaces Ethernet, comme montré à la Figure 1.
---------------------------------------------------------------
| a node |
| |
| |
| |
| |
| |
| /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ |
| |
| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
---------------------------------------------------------------
: | | | |
: | | | |
: | | | |
(imaginary ================= a point- a
loopback an Ethernet to-point tunnel
link) link)
Figure 2: Example of Default Zone Indices
En plus d'assigner initialement les indices de zone, comme spécifié ci-dessus, une implémentation devrait automatiquement sélectionner une zone par défaut pour chaque portée pour laquelle il y a plus d'un choix, à utiliser chaque fois qu'une adresse est spécifiée sans indice de zone (ou avec un indice de zone de zéro). Par exemple, dans l'exemple montré à la Figure 2, l'implémentation pourrait automatiquement sélectionner intf2 et link2 comme zones par défaut pour chacune de ces deux portées. (Un algorithme de sélection possible est de choisir la première zone qui inclut une interface autre que l'interface de bouclage comme la par défaut pour chaque portée.) Un moyen doit également être fourni pour assigner la zone par défaut pour une portée manuellement, en remplaçant toute assignation automatique.
L'adresse unicast de bouclage, ::1, ne peut pas être assignée à une interface autre que l'interface de bouclage. Par conséquent, il est recommandé que, chaque fois que ::1 est spécifié sans indice de zone ou avec l'indice de zone par défaut, elle soit interprétée comme appartenant à la zone locale au lien de bouclage, indépendamment de la zone locale au lien qui a été sélectionnée comme la par défaut. Si cela est fait, alors pour les nœuds avec seulement une seule interface non-bouclage (par exemple, une seule interface Ethernet), le cas courant, les adresses locales au lien n'ont pas besoin d'être qualifiées avec un indice de zone. L'adresse non qualifiée ::1 se référerait toujours à la zone locale au lien contenant l'interface de bouclage. Toutes les autres adresses locales au lien non qualifiées se référeraient à la zone locale au lien contenant l'interface non-bouclage (tant que la zone locale au lien par défaut était définie comme la zone contenant l'interface non-bouclage).
Du fait de l'exigence qu'une zone d'une portée donnée se situe complètement dans les zones de portée plus grande (voir Section 5, ci-dessus), deux interfaces assignées à différentes zones de portée S doivent également être assignées à différentes zones de toutes les portées plus petites que S. Ainsi, l'assignation manuelle d'indices de zone distincts pour une portée peut nécessiter l'assignation automatique d'indices de zone distincts pour les portées plus petites. Par exemple, supposons que les indices distincts de multidiffusion locale au site 1 et 2 soient manuellement assignés à la Figure 1 et que le site 1 contient les liens 1, 2 et 3, mais que le site 2 ne contient que le lien 4. Cette configuration causerait la création automatique correspondante d'indices au niveau administratif (c'est-à-dire la valeur "scop" de multidiffusion 4) 1 et 2, parce que la portée au niveau administratif est plus petite que la portée locale au site.
Avec les considérations ci-dessus, l'ensemble complet des indices de zone pour notre nœud d'exemple de la Figure 1, avec les configurations supplémentaires ici, est montré à la Figure 3, ci-dessous.
---------------------------------------------------------------
| a node |
| |
| |
| |
| |
| |
| /--------------------site1--------------------\ /--site2--\ |
| |
| /-------------------admin1--------------------\ /-admin2--\ |
| |
| /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ |
| |
| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
---------------------------------------------------------------
: | | | |
: | | | |
: | | | |
(imaginary ================= a point- a
loopback an Ethernet to-point tunnel
link) link)
Figure 3: Complete Zone Indices Example
Bien que les exemples ci-dessus montrent les zones étant assignées des valeurs d'indice séquentielles pour chaque portée, en commençant à un, les valeurs d'indice de zone sont arbitraires. Une implémentation peut étiqueter une zone avec n'importe quelle valeur qu'elle choisit, tant que la valeur d'indice de chaque zone de toutes les portées est unique au sein du nœud. Le zéro DEVRAIT être réservé pour représenter la zone par défaut. Les implémentations choisissant de suivre l'API basique recommandée [10] voudront restreindre leurs valeurs d'indice à celles qui peuvent être représentées par le champ sin6_scope_id de la structure sockaddr_in6.