5. Sélection d'adresse source

L'algorithme de sélection d'adresse source produit en sortie une seule adresse source pour utilisation avec une adresse de destination donnée. Cet algorithme s'applique uniquement aux adresses de destination IPv6, pas aux adresses IPv4.

L'algorithme est spécifié ici en termes d'une liste de règles de comparaison par paires qui (pour une adresse de destination D donnée) impose un ordre "supérieur à" sur les adresses dans l'ensemble candidat CandidateSource(D). L'adresse au début de la liste après que l'algorithme soit terminé est celle que l'algorithme sélectionne.

Notez que conceptuellement, un tri de l'ensemble candidat est effectué, où un ensemble de règles définit l'ordonnancement parmi les adresses. Mais parce que la sortie de l'algorithme est une seule adresse source, une implémentation n'a pas besoin de trier réellement l'ensemble; elle a seulement besoin d'identifier la valeur "maximale" qui se retrouve au début de la liste triée.

L'ordonnancement des adresses dans l'ensemble candidat est défini par une liste de huit règles de comparaison par paires, chaque règle plaçant un ordre "supérieur à", "inférieur à" ou "égal à" sur deux adresses source l'une par rapport à l'autre (et cette règle). Dans le cas où une règle donnée produit une égalité, c'est-à-dire fournit un résultat "égal à" pour les deux adresses, les règles restantes DOIVENT être appliquées (dans l'ordre) uniquement à ces adresses qui sont à égalité pour rompre l'égalité. Notez que si une règle produit un seul "gagnant" clair (ou un ensemble de "gagnants" dans le cas d'égalités), ces adresses qui ne sont pas dans l'ensemble gagnant peuvent être écartées de toute considération ultérieure, avec les règles suivantes appliquées uniquement aux adresses restantes. Si les huit règles échouent à choisir une seule adresse, le départage est spécifique à l'implémentation.

Lors de la comparaison de deux adresses SA et SB de l'ensemble candidat, nous disons "préférer SA" pour signifier que SA est "supérieur à" SB, et de même, nous disons "préférer SB" pour signifier que SA est "inférieur à" SB. Si aucune n'est déclarée préférée, cela signifie que SA est "égal à" SB, et les règles restantes s'appliquent comme noté ci-dessus.

Règle 1: Préférer la même adresse.
Si SA = D, alors préférer SA. De même, si SB = D, alors préférer SB.

Règle 2: Préférer la portée appropriée.
Si Scope(SA) < Scope(SB): Si Scope(SA) < Scope(D), alors préférer SB et sinon préférer SA. De même, si Scope(SB) < Scope(SA): Si Scope(SB) < Scope(D), alors préférer SA et sinon préférer SB.

Discussion: Cette règle doit avoir une priorité élevée car elle peut affecter l'interopérabilité.

Règle 3: Éviter les adresses dépréciées.
Si l'une des deux adresses source est "préférée" et l'une d'elles est "dépréciée" (au sens du RFC 4862), alors préférer celle qui est "préférée".

Règle 4: Préférer les adresses personnelles.
Si SA est simultanément une adresse personnelle et une adresse de correspondance et SB ne l'est pas, alors préférer SA. De même, si SB est simultanément une adresse personnelle et une adresse de correspondance et SA ne l'est pas, alors préférer SB. Si SA est juste une adresse personnelle et SB est juste une adresse de correspondance, alors préférer SA. De même, si SB est juste une adresse personnelle et SA est juste une adresse de correspondance, alors préférer SB.

Les implémentations supportant les adresses personnelles DOIVENT fournir un mécanisme permettant à une application d'inverser le sens de cette préférence et de préférer les adresses de correspondance aux adresses personnelles (par exemple, via des extensions API appropriées telles que [RFC5014]). L'utilisation du mécanisme DOIT affecter uniquement les règles de sélection pour l'application invocatrice.

Règle 5: Préférer l'interface sortante.
Si SA est assignée à l'interface qui sera utilisée pour envoyer à D et SB est assignée à une interface différente, alors préférer SA. De même, si SB est assignée à l'interface qui sera utilisée pour envoyer à D et SA est assignée à une interface différente, alors préférer SB.

Règle 5.5: Préférer les adresses dans un préfixe annoncé par le prochain saut.
Si SA ou le préfixe de SA est assigné par le prochain saut sélectionné qui sera utilisé pour envoyer à D et SB ou le préfixe de SB est assigné par un prochain saut différent, alors préférer SA. De même, si SB ou le préfixe de SB est assigné par le prochain saut qui sera utilisé pour envoyer à D et SA ou le préfixe de SA est assigné par un prochain saut différent, alors préférer SB.

Discussion: Une implémentation IPv6 n'est pas requise de mémoriser quels prochains sauts ont annoncé quels préfixes. Les modèles conceptuels des hôtes IPv6 dans la Section 5 de [RFC4861] et la Section 3 de [RFC4191] n'ont pas une telle exigence. Par conséquent, la règle 5.5 n'est applicable qu'aux implémentations qui suivent cette information.

Règle 6: Préférer l'étiquette correspondante.
Si Label(SA) = Label(D) et Label(SB) <> Label(D), alors préférer SA. De même, si Label(SB) = Label(D) et Label(SA) <> Label(D), alors préférer SB.

Règle 7: Préférer les adresses temporaires.
Si SA est une adresse temporaire et SB est une adresse publique, alors préférer SA. De même, si SB est une adresse temporaire et SA est une adresse publique, alors préférer SB.

Les implémentations DOIVENT fournir un mécanisme permettant à une application d'inverser le sens de cette préférence et de préférer les adresses publiques aux adresses temporaires (par exemple, via des extensions API appropriées telles que [RFC5014]). L'utilisation du mécanisme DOIT affecter uniquement les règles de sélection pour l'application invocatrice. Ce défaut est destiné à adresser les préoccupations de confidentialité comme discuté dans [RFC4941] mais introduit un risque d'échec potentiel des applications en raison de la durée de vie relativement courte des adresses temporaires ou en raison de la possibilité que la recherche inverse d'une adresse temporaire échoue ou retourne un nom aléatoire. Les implémentations pour lesquelles les considérations de compatibilité d'application l'emportent sur ces préoccupations de confidentialité PEUVENT inverser le sens de cette règle et préférer par défaut les adresses publiques aux adresses temporaires. Il DEVRAIT y avoir une option administrative (le drapeau de préférence de confidentialité) pour changer cette préférence, si l'implémentation supporte les adresses temporaires. S'il n'y a pas une telle option, il DOIT y avoir une option administrative pour désactiver les adresses temporaires.

Règle 8: Utiliser le préfixe correspondant le plus long.
Si CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), alors préférer SA. De même, si CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), alors préférer SB.

La règle 8 PEUT être remplacée si l'implémentation a d'autres moyens de choisir parmi les adresses source. Par exemple, si l'implémentation sait d'une manière ou d'une autre quelle adresse source résultera en la "meilleure" performance de communication.