Résumé

  • La RFC 3316 décrivait GPRS et UMTS comme des liaisons IPv6 point à point : après la découverte des routeurs, le seul voisin de l’hôte était son routeur par défaut, et aucune adresse de couche liaison n’était à résoudre.
  • Cela supprimait la résolution d’adresse, pas la nécessité de savoir si le routeur restait joignable. La détection d’injoignabilité des voisins demeurait pertinente ; TCP, RTCP ou SIP pouvaient parfois fournir une preuve circonscrite de communication dans les deux sens et éviter une sonde redondante.

Analyse

En 2003, le titre de la RFC 3316 disait soigneusement « certains » hôtes cellulaires de deuxième et troisième générations. Ce texte à caractère informatif s’adressait aux personnes qui implémentaient des hôtes GPRS et UMTS selon les versions visées. Il ne créait pas une nouvelle norme IPv6 et ne constituait pas une liste universelle pour chaque radio, ordinateur portable ou routeur cellulaire. Son introduction déconseillait explicitement d’étendre ces recommandations à d’autres types de liaison sans analyse.

Cette limite comptait parce que les procédures IPv6 habituelles rencontraient ici une liaison inhabituelle. Sur un Ethernet partagé, un hôte peut devoir convertir l’adresse IPv6 d’un voisin en adresse de couche liaison avant d’envoyer un paquet. La RFC 3316 décrivait GPRS et UMTS autrement : la liaison ressemblait à une connexion point à point, le seul voisin de l’hôte était le routeur par défaut et la découverte des routeurs l’avait déjà identifié. Sans adresse de couche liaison sur cette interface, la résolution d’adresse et la détermination du prochain saut n’avaient pas de rôle à jouer.

Il serait tentant d’en tirer une mauvaise conclusion : s’il n’existe aucune adresse MAC à rechercher, alors il n’y a peut-être aucun état de voisin à maintenir. La RFC ne disait pas cela. Le même passage exigeait que l’hôte prenne en charge la détection d’injoignabilité des voisins, ou NUD, dans l’architecture générale de découverte des voisins IPv6. La résolution d’adresse demande comment construire une destination de couche liaison. La NUD demande si un voisin déjà connu reste joignable. La première question pouvait disparaître sans que la seconde disparaisse.

La raison était opérationnelle. Pour atteindre des destinations au-delà de son lien immédiat, l’hôte a toujours besoin d’un prochain saut fonctionnel. Une liaison point à point indique quel routeur se trouve de l’autre côté ; elle ne prouve pas qu’il reste joignable à tout instant. Découverte des routeurs, configuration d’adresse, résolution de couche liaison et joignabilité du voisin sont des étapes liées, mais leurs preuves ne sont pas interchangeables.

La bande passante cellulaire justifiait aussi de s’interroger sur les messages de contrôle répétés. La RFC proposait d’utiliser les confirmations de joignabilité de la couche supérieure lorsque l’hôte pouvait déjà établir une communication IP bidirectionnelle. TCP pouvait fournir une telle confirmation selon le mécanisme de la spécification de découverte des voisins. Pour RTP transporté par UDP, un rapport de réception RTCP montrant que des paquets étaient arrivés pouvait indiquer que le pair — et donc le voisin — avait reçu du trafic.

Les réponses SIP pouvaient confirmer la réception des requêtes ; dans un cas plus restreint côté serveur, recevoir un ACK SIP pouvait indiquer qu’une réponse antérieure était parvenue au pair. UDP, à lui seul, ne fournissait pas cette confirmation.

Il ne s’agissait pas de rendre la NUD obsolète grâce aux applications. Une réponse utile déjà présente sur le réseau pouvait répondre à une question limitée de joignabilité sans ajouter une sonde. Mais toute preuve avait une portée : un rapport RTCP disait quelque chose sur la réception de paquets ; une réponse SIP, sur un échange SIP. Ni l’un ni l’autre ne démontrait qu’une opération applicative était terminée, que toutes les routes fonctionnaient ou que l’utilisateur avait obtenu le service. Un flux UDP silencieux ne devenait pas une preuve par le seul fait que le lien n’avait pas d’adresse MAC.

Les autres adaptations cellulaires de la RFC renforcent cette distinction. La section consacrée à IPv6 sur PPP examinait l’identifiant d’interface lien-local suggéré par le terminal mobile à l’équipement raccordé ; elle n’interdisait pas à ce dernier d’utiliser d’autres identifiants pour ses adresses globales ou temporaires. La configuration sans état reposait également sur des préfixes uniques dans leur portée afin d’éviter la détection d’adresses dupliquées sur l’interface cellulaire. Il s’agissait d’adaptations précises à différentes couches, pas de la suppression générale des vérifications IPv6.

En 2013, la RFC 7066 a remplacé la RFC 3316 et élargi le cadre 3GPP documenté pour inclure l’Evolved Packet System, en plus de GPRS et UMTS. Elle a conservé l’explication fondée sur l’absence d’adresses de couche liaison et le maintien de la NUD, tout en précisant qu’une passerelle GGSN ou PGW pouvait ne pas répondre à une sollicitation de résolution d’adresse. Cette succession montre l’évolution du profil au rythme du périmètre 3GPP ; elle ne révèle pas combien d’appareils ont adopté une conduite donnée.

La RFC 8504 est aujourd’hui le document général sur les exigences IPv6 des nœuds : la RFC 3316 ne doit pas être présentée comme la liste complète actuelle.

La leçon durable est plus étroite et plus utile que « les liaisons cellulaires sont spéciales ». Un type de liaison peut rendre inutile une opération générique tout en laissant intacte la question sous-jacente. Ici, aucune adresse de couche liaison ne devait être découverte, mais l’hôte avait encore besoin d’indices de joignabilité. Lorsque les couches supérieures pouvaient les fournir, elles permettaient de réduire des messages redondants sans devenir une preuve de bon fonctionnement de tout le service.

Sources

Les RFC décrivent des recommandations protocolaires. Elles ne mesurent ni les économies de signalisation, ni la fiabilité radio, ni l’autonomie, ni le taux de déploiement, ni l’expérience des utilisateurs.