2. Contexte dans lequel les algorithmes opèrent

Notre contexte pour la sélection d'adresse dérive de l'architecture d'implémentation la plus courante, qui sépare le choix d'adresse de destination du choix d'adresse source. Par conséquent, nous avons deux algorithmes séparés pour ces tâches. Les algorithmes sont conçus pour bien fonctionner ensemble, et ils partagent un mécanisme pour le remplacement de politique administrative.

Dans cette architecture d'implémentation, les applications utilisent des API telles que getaddrinfo() [RFC3493] qui retournent une liste d'adresses à l'application. Cette liste pourrait contenir à la fois des adresses IPv6 et IPv4 (parfois représentées comme des adresses mappées IPv4). L'application passe ensuite une adresse de destination à la pile réseau avec connect() ou sendto(). L'application essaierait alors typiquement la première adresse dans la liste, bouclant sur la liste d'adresses jusqu'à ce qu'elle trouve une adresse fonctionnelle. Dans tous les cas, la couche réseau n'est jamais dans une situation où elle a besoin de choisir une adresse de destination parmi plusieurs alternatives. L'application pourrait également spécifier une adresse source avec bind(), mais souvent l'adresse source est laissée non spécifiée. Par conséquent, la couche réseau choisit souvent une adresse source parmi plusieurs alternatives.

En conséquence, nous prévoyons que les implémentations d'API telles que getaddrinfo() utiliseront l'algorithme de sélection d'adresse de destination spécifié ici pour trier la liste d'adresses IPv6 et IPv4 qu'elles retournent. Séparément, la couche réseau IPv6 utilisera l'algorithme de sélection d'adresse source lorsqu'une application ou couche supérieure n'a pas spécifié d'adresse source. L'application de cette spécification à la sélection d'adresse source dans une couche réseau IPv4 pourrait être possible, mais ceci n'est pas exploré davantage ici.

Les applications bien conçues NE DEVRAIENT PAS simplement utiliser la première adresse retournée par une API telle que getaddrinfo() puis abandonner si elle échoue. Pour beaucoup d'applications, il est approprié d'itérer à travers la liste d'adresses retournée par getaddrinfo() jusqu'à ce qu'une adresse fonctionnelle soit trouvée. Pour d'autres applications, il pourrait être approprié d'essayer plusieurs adresses en parallèle (par exemple, avec un petit délai entre elles) et d'utiliser la première qui réussit.

Bien que la sélection d'adresse source et de destination soit le plus typiquement effectuée lors de l'initiation de communication, un répondeur doit également gérer la sélection d'adresse. Dans de nombreux cas, ceci est trivialement géré par une application utilisant l'adresse source d'un paquet reçu comme destination de réponse et l'adresse de destination du paquet reçu comme source de réponse. D'autres cas, cependant, sont gérés comme un initiateur, comme lorsque la requête est multicast et donc la sélection d'adresse source doit encore se produire lors de la génération d'une réponse ou lorsque la requête inclut une liste des adresses de l'initiateur parmi lesquelles choisir une destination. Enfin, un troisième scénario d'application est celui d'une application en écoute choisissant sur quelles adresses locales écouter. Ce troisième scénario est hors du champ d'application de ce document.

Les algorithmes utilisent plusieurs critères pour prendre leurs décisions. L'effet combiné est de préférer les paires d'adresses destination/source pour lesquelles les deux adresses sont de portée ou type égal, préférer les portées plus petites aux portées plus grandes pour l'adresse de destination, préférer les adresses source non dépréciées, éviter l'utilisation d'adresses transitionnelles quand des adresses natives sont disponibles, et toutes choses égales par ailleurs, préférer les paires d'adresses ayant le préfixe commun le plus long possible. Pour la sélection d'adresse source, les adresses temporaires [RFC4941] sont préférées aux adresses publiques. Dans les situations mobiles [RFC6275], les adresses personnelles sont préférées aux adresses de correspondance. Si une adresse est simultanément une adresse personnelle et une adresse de correspondance (indiquant que le nœud mobile est "chez lui" pour cette adresse), alors l'adresse personnelle/de correspondance est préférée aux adresses qui sont uniquement une adresse personnelle ou uniquement une adresse de correspondance.

Cette spécification permet optionnellement la possibilité de configuration administrative de politique (par exemple, via configuration manuelle ou une option DHCP telle que celle proposée dans [ADDR-SEL-OPT]) qui peut remplacer le comportement par défaut des algorithmes. Le remplacement de politique consiste en l'ensemble d'états suivant, qui DEVRAIT être configurable:

Table de politique (Section 2.1): une table qui spécifie les valeurs de précédence et les préfixes source préférés pour les préfixes de destination.
Drapeau d'ajouts automatiques de lignes (Section 2.1): un drapeau qui spécifie si l'implémentation est autorisée à ajouter automatiquement des lignes spécifiques au site pour certains types d'adresses.
Drapeau de préférence de confidentialité (Section 5): un drapeau qui spécifie si les adresses source temporaires ou les adresses source stables sont préférées par défaut lorsque les deux types existent.