4. Protocol Overview (Aperçu du protocole)
Cette section donne un aperçu des étapes typiques qui se produisent lorsqu'une interface se configure automatiquement. La configuration automatique n'est effectuée que sur les liens qui supportent le multicast et commence lorsqu'une interface supportant le multicast est activée, par exemple pendant le démarrage du système. Les nœuds (hôtes et routeurs) commencent le processus de configuration automatique en générant une adresse link-local pour l'interface. L'adresse link-local est formée en ajoutant l'identifiant de l'interface au préfixe link-local bien connu [RFC4291].
Cependant, avant qu'une adresse link-local ne soit affectée à une interface et utilisée, un nœud doit (MUST) tenter de vérifier que cette adresse « provisoire (Tentative) » n'est pas déjà utilisée par un autre nœud sur le lien. Plus précisément, il envoie un message de sollicitation de voisin (Neighbor Solicitation) contenant l'adresse provisoire comme cible. Si un autre nœud utilise déjà cette adresse, il renverra une annonce de voisin (Neighbor Advertisement) l'indiquant. Si un autre nœud tente également d'utiliser la même adresse, il enverra également une sollicitation de voisin pour la cible. Le nombre exact de (re)transmissions de sollicitations de voisin et le délai entre les sollicitations consécutives sont spécifiques au lien et peuvent (MAY) être définis par la configuration du système d'administration.
Si un nœud détermine que son adresse link-local provisoire n'est pas unique, la configuration automatique s'arrête et une configuration manuelle de l'interface est nécessaire. Pour simplifier la récupération dans ce cas, un administrateur devrait (SHOULD) pouvoir fournir un identifiant d'interface alternatif qui remplace l'identifiant par défaut, de sorte que le mécanisme de configuration automatique puisse être appliqué avec un nouvel identifiant d'interface (peut-être unique). Alternativement, une configuration manuelle de l'adresse link-local et d'autres adresses est nécessaire.
Une fois qu'un nœud détermine que son adresse link-local provisoire est unique, il affecte l'adresse à l'interface. À ce stade, le nœud a une connectivité de niveau IP avec les nœuds voisins. Les étapes de configuration automatique restantes ne sont effectuées que par les hôtes ; la configuration (automatique) des routeurs dépasse le cadre de ce document.
La phase suivante de la configuration automatique consiste à obtenir une annonce de routeur (Router Advertisement) ou à déterminer qu'aucun routeur n'est présent. Si des routeurs sont présents, ils enverront des annonces de routeur spécifiant le type de configuration automatique qu'un hôte peut effectuer. Il convient de noter que même en l'absence de routeurs, un service DHCPv6 pour la configuration d'adresse peut (MAY) toujours être disponible.
Les routeurs envoient périodiquement des annonces de routeur, mais le délai entre les annonces consécutives sera généralement plus long que le temps qu'un hôte effectuant la configuration automatique souhaiterait attendre [RFC4861]. Pour obtenir rapidement une annonce, un hôte envoie une ou plusieurs sollicitations de routeur (Router Solicitation) au groupe multicast de tous les routeurs.
Les annonces de routeur contiennent également zéro ou plusieurs options d'information de préfixe (Prefix Information), qui contiennent des informations utilisées par la configuration automatique d'adresse sans état pour générer des adresses globales. Il convient de noter qu'un hôte devrait (SHOULD) utiliser simultanément la configuration automatique d'adresse sans état et DHCPv6. Un champ d'option d'information de préfixe, le « drapeau de configuration d'adresse autonome (Autonomous Address-Configuration Flag) », indique si l'option s'applique même à la configuration automatique sans état. Si elle s'applique, des champs d'option supplémentaires contiennent le préfixe de sous-réseau ainsi que des valeurs de durée de vie indiquant combien de temps les adresses créées à partir du préfixe restent préférées et valides.
Étant donné que les routeurs génèrent périodiquement des annonces de routeur, les hôtes recevront continuellement de nouvelles annonces. Les hôtes traitent les informations contenues dans chaque annonce, comme décrit ci-dessus, en ajoutant et en rafraîchissant les informations reçues dans les annonces précédentes.
Par défaut, à des fins de sécurité, tous les adresses devraient (SHOULD) être testées pour leur unicité avant d'être affectées à une interface. Ce test devrait (SHOULD) être effectué individuellement sur toutes les adresses obtenues manuellement, via la configuration automatique d'adresse sans état ou via DHCPv6. Pour accommoder les sites qui estiment que le surcoût de l'exécution de la détection d'adresse dupliquée l'emporte sur ses avantages, l'utilisation de la détection d'adresse dupliquée peut (MAY) être désactivée par configuration d'administration d'un drapeau de configuration par interface.
Pour accélérer le processus de configuration automatique, un hôte peut (MAY) générer son adresse link-local (et vérifier son unicité) en parallèle de l'attente d'une annonce de routeur. Étant donné que les routeurs peuvent retarder de quelques secondes leur réponse aux sollicitations de routeur, si ces deux étapes sont effectuées en série, le temps total nécessaire pour terminer la configuration automatique peut être considérablement plus long.
4.1. Site Renumbering (Renumérotation de site)
Les baux d'adresse facilitent la renumérotation de site en fournissant un mécanisme pour le timeout des adresses affectées aux interfaces dans les hôtes. Actuellement, les protocoles de couche supérieure (tels que TCP) ne supportent pas le changement des adresses des points d'extrémité pendant qu'une connexion est ouverte. Si une adresse de point d'extrémité devient invalide, les connexions existantes se rompent et toute communication avec l'adresse invalide échoue. Même si une application utilise UDP comme protocole de transport, les adresses doivent généralement rester les mêmes pendant un échange de paquets.
La division des adresses valides en catégories préférées et dépréciées fournit un moyen d'indiquer aux couches supérieures qu'une adresse valide peut bientôt devenir invalide et que toute communication future utilisant cette adresse échouera si la durée de vie valide de l'adresse expire avant la fin de la communication. Pour éviter cela, les couches supérieures devraient (SHOULD) utiliser des adresses préférées (en supposant que des adresses de portée suffisante existent) pour augmenter la probabilité qu'une adresse reste valide pendant la durée de la communication. Les administrateurs système devraient (SHOULD) définir des durées de vie de préfixe appropriées pour minimiser l'impact des communications échouées lorsqu'une renumérotation se produit. La période de dépréciation devrait (SHOULD) être suffisamment longue pour que la plupart (sinon toutes) des communications utilisent une nouvelle adresse au moment où une adresse devient invalide.
Il est attendu que la couche IP fournisse un moyen aux couches supérieures (y compris les applications) de sélectionner l'adresse source la plus appropriée, étant donné une destination particulière et éventuellement d'autres contraintes. Les applications peuvent (MAY) choisir de sélectionner elles-mêmes l'adresse source avant de commencer une nouvelle communication, ou peuvent (MAY) choisir de ne pas spécifier d'adresse, auquel cas la couche réseau supérieure utilisera le mécanisme fourni par la couche IP pour sélectionner une adresse appropriée au nom de l'application.
Les règles détaillées de sélection d'adresse dépassent le cadre de ce document et sont décrites dans [RFC3484].