11.7. Combinaisons de caractères délimiteurs

Il y a d'autres types de caractères délimiteurs définis pour les adresses IPv6. Dans cette sous-section, nous décrivons comment ils devraient être combinés avec le format pour les adresses non globales.

L'architecture d'adressage IPv6 [1] définit également la syntaxe des préfixes IPv6. Si la partie adresse d'un préfixe est non globale et sa zone de portée devrait être désambiguïsée, la partie adresse DEVRAIT être au format. Par exemple, un préfixe local au lien fe80::/64 sur le deuxième lien peut être représenté comme suit:

fe80::%2/64

Dans cette combinaison, il est important de placer la partie indice de zone avant la longueur du préfixe lorsque nous considérons l'analyse du format par une fonction de bibliothèque de traduction nom-à-adresse [11]. C'est-à-dire que nous pouvons d'abord séparer l'adresse avec l'indice de zone de la longueur du préfixe, et simplement passer le premier à la fonction de bibliothèque.

Le format préféré pour les adresses IPv6 littérales dans les URL est également défini [12]. Lorsqu'un utilisateur tape le format préféré pour une adresse IPv6 non globale dont la zone devrait être explicitement spécifiée, l'utilisateur pourrait utiliser le format pour l'adresse non globale combinée avec le format préféré.

Cependant, l'URL tapée est souvent envoyée sur le fil, et cela causerait de la confusion si une application ne dépouillait pas la partie <zone_id> avant d'envoyer. Notez que les applications ne devraient pas avoir besoin de se soucier du type d'adresses qu'elles utilisent, et encore moins analyser ou dépouiller la partie <zone_id> de l'adresse.

De plus, le format pour les adresses non globales pourrait entrer en conflit avec la syntaxe URI [13], puisque la syntaxe définit le caractère délimiteur (%) comme le caractère d'échappement. Ce conflit nécessiterait, par exemple, que la partie <zone_id> pour la zone 1 avec le délimiteur soit représentée comme '%251'. Cela signifie également que nous ne pourrions pas simplement copier un format non échappé d'autres sources comme entrée pour l'analyseur URI. De plus, si l'analyseur URI ne convertit pas le format échappé avant de le passer à une bibliothèque de traduction nom-à-adresse, la conversion échouera. Tous ces problèmes diminueraient le bénéfice de la représentation textuelle décrite dans cette section.

Par conséquent, ce document ne spécifie pas comment le format pour les adresses non globales devrait être combiné avec le format préféré pour les adresses IPv6 littérales. En tout cas, il est recommandé d'utiliser un FQDN au lieu d'une adresse IPv6 littérale dans une URL, chaque fois qu'un FQDN est disponible.