4.5. Application and Higher Level Protocol Issues (Problèmes d'Application et de Protocoles de Niveau Supérieur)

4.5. Application and Higher Level Protocol Issues (Problèmes d'Application et de Protocoles de Niveau Supérieur)

Les applications et autres protocoles de niveau supérieur peuvent traiter les adresses IPv6 locales de la même manière que d'autres types d'adresses unicast globales. Aucune gestion spéciale n'est requise. Ce type d'adresse peut ne pas être accessible, mais cela ne diffère pas d'autres types d'adresses unicast globales IPv6. Les applications doivent être capables de gérer plusieurs adresses qui peuvent ou non être accessibles à tout moment. Dans la plupart des cas, cette complexité devrait être cachée dans les API.

Du point de vue d'un hôte, la différence entre les adresses IPv6 locales et d'autres types d'adresses unicast globales se manifeste comme une accessibilité différente et pourrait être gérée de cette manière par défaut. Dans certains cas, il est préférable que les nœuds et les applications les traitent différemment des adresses unicast globales. Un point de départ pourrait être de leur donner la préférence sur les adresses unicast globales, mais de revenir aux adresses unicast globales si une destination particulière s'avère inaccessible. Une grande partie de ce comportement peut être contrôlée par la façon dont elles sont allouées aux nœuds et insérées dans le DNS. Cependant, il est utile qu'un hôte puisse avoir les deux types d'adresses et les utiliser de manière appropriée.

Notez que les mécanismes de sélection d'adresse de [ADDSEL], et en particulier le mécanisme de remplacement de politique remplaçant la sélection d'adresse par défaut, sont censés être utilisés sur un site où des adresses IPv6 locales sont configurées.