1. Introduction

L'architecture d'adressage IPv6 [RFC4291] permet d'assigner plusieurs adresses unicast aux interfaces. Ces adresses peuvent avoir différentes portées de joignabilité (link-local, site-local ou global). Ces adresses peuvent également être "préférées" ou "dépréciées" [RFC4862]. Les considérations de confidentialité ont introduit les concepts d'"adresses publiques" et d'"adresses temporaires" [RFC4941]. L'architecture de mobilité introduit les "adresses personnelles" (home addresses) et les "adresses de correspondance" (care-of addresses) [RFC6275]. De plus, les situations de multi-homing résulteront en davantage d'adresses par nœud. Par exemple, un nœud pourrait avoir plusieurs interfaces, certaines d'entre elles étant des tunnels ou des interfaces virtuelles, ou un site pourrait avoir plusieurs attachements ISP avec un préfixe global par ISP.

Le résultat final est que les implémentations IPv6 seront très souvent confrontées à plusieurs adresses source et de destination possibles lors de l'initiation de communication. Il est souhaitable d'avoir des algorithmes par défaut, communs à toutes les implémentations, pour sélectionner les adresses source et de destination afin que les développeurs et administrateurs puissent raisonner et prédire le comportement de leurs systèmes.

De plus, les implémentations à double pile ou hybrides, qui supportent à la fois IPv6 et IPv4, devront très souvent choisir entre IPv6 et IPv4 lors de l'initiation de communication, par exemple, lorsque la résolution de nom DNS fournit à la fois des adresses IPv6 et IPv4 et que la pile de protocoles réseau dispose à la fois d'adresses source IPv6 et IPv4. Dans de tels cas, une politique simple consistant à toujours préférer IPv6 ou toujours préférer IPv4 peut produire un mauvais comportement. À titre d'exemple, supposons qu'un nom DNS se résolve en une adresse IPv6 globale et une adresse IPv4 globale. Si le nœud a une adresse IPv6 globale assignée et une adresse IPv4 auto-configurée 169.254/16 [RFC3927], alors IPv6 est le meilleur choix pour la communication. Mais si le nœud a assigné seulement une adresse IPv6 link-local et une adresse IPv4 globale, alors IPv4 est le meilleur choix pour la communication. L'algorithme de sélection d'adresse de destination résout ceci avec une procédure unifiée pour choisir parmi les adresses IPv6 et IPv4.

Les algorithmes dans ce document sont spécifiés comme un ensemble de règles qui définissent un ordre partiel sur l'ensemble des adresses disponibles pour utilisation. Dans le cas de la sélection d'adresse source, un nœud a typiquement plusieurs adresses assignées à ses interfaces, et les règles d'ordonnancement d'adresse source dans la Section 5 définissent quelle adresse est la "meilleure" à utiliser. Dans le cas de la sélection d'adresse de destination, le DNS pourrait retourner un ensemble d'adresses pour un nom donné, et une application a besoin de décider laquelle utiliser en premier et dans quel ordre essayer les autres si la première n'est pas joignable. Les règles d'ordonnancement d'adresse de destination dans la Section 6, lorsqu'appliquées à l'ensemble d'adresses retourné par le DNS, fournissent un tel ordre recommandé.

Ce document spécifie la sélection d'adresse source et la sélection d'adresse de destination séparément mais utilise un contexte commun de sorte qu'ensemble les deux algorithmes donnent des résultats utiles. Les algorithmes tentent de choisir des adresses source et de destination de portée et de statut de configuration appropriés ("préférée" ou "dépréciée" au sens du RFC 4862). De plus, ce document suggère une méthode préférée, le préfixe correspondant le plus long, pour choisir parmi des adresses autrement équivalentes en l'absence de meilleure information.

Ce document spécifie également des points d'ancrage de politique pour permettre un remplacement administratif du comportement par défaut. Par exemple, en utilisant ces points d'ancrage, un administrateur peut spécifier un préfixe source préféré pour utilisation avec un préfixe de destination ou préférer des adresses de destination avec un préfixe plutôt que des adresses avec un autre préfixe. Ces points d'ancrage donnent à un administrateur une flexibilité pour gérer certains scénarios de multi-homing et de transition, mais ils ne sont certainement pas une panacée.

Les règles de sélection spécifiées dans ce document NE DOIVENT PAS être interprétées comme remplaçant le choix explicite d'une application ou d'une couche supérieure d'une adresse de destination ou source légale.