Ce que négocie IPv6CP, et ce qui a encore besoin d'un préfixe
Une adresse link-local sur l'interface PPP est une étape de configuration, pas un accès IPv6. Séparez l'échange d'identifiants des préfixes, des routes et de l'intégration du client.
IPv6 monte sur l'interface PPP, une adresse link-local apparaît, et le changement est déclaré terminé. Ensuite rien n'est routé, aucune adresse globale n'existe, et un test vers une destination publique échoue alors que l'interface semble toujours configurée. La liaison est montée ; le réseau, jamais. Passez les quatre vérifications ci-dessous dans l'ordre et arrêtez-vous à celle qui explique l'écart.
Ce qu'une adresse link-local prouve réellement
IPv6CP active IPv6 sur la liaison PPP et négocie un identifiant d'interface pour chaque côté. Cet identifiant produit une adresse link-local, qui suffit à parler au pair à travers la liaison et ne suffit pas à atteindre autre chose. L'adresse prouve que la liaison est prête pour IPv6, et elle ne prouve rien sur le réseau derrière le pair. La lire comme une adresse d'accès est l'erreur par laquelle commencent la plupart de ces enquêtes.
Les quatre questions ci-dessous séparent ce que règle la couche liaison de ce que le service doit fournir. Répondez-y dans l'ordre, car on ne peut pas répondre à une question ultérieure tant qu'une précédente reste ouverte.
| Question | Answered by | What it does not settle |
|---|---|---|
| Is IPv6 up on the link? | IPv6CP: interface identifiers, then link-local addresses | Any address reachable beyond the peer |
| Where does a global prefix come from? | Router advertisement, delegated prefix, DHCPv6 or static configuration | IPv6CP carries no prefix of its own |
| Who owns the routes? | The client's tunnel configuration and the server's return path | A link-local address implies no route at all |
| How does this client get configured? | Explicit tunnel settings or router advertisements, depending on the client | The standard does not choose for the implementation |
D'où le préfixe doit venir
Une adresse globale a besoin d'un préfixe venu de quelque part : une annonce de routeur, un préfixe délégué, DHCPv6 ou une configuration statique. IPv6CP n'en transporte aucun, et aucune attente sur la liaison n'en produira. RFC 5072 place IPv6CP comme l'étape de configuration qui s'exécute avant que d'autres protocoles IPv6 n'opèrent sur la liaison, et c'est toute sa portée : préparer la liaison, pas numéroter le réseau. Fournissez le préfixe et l'interface se met à transporter du trafic au lieu de simplement exister.
Les annonces de routeur sont la réponse courante sur un LAN et une réponse moins fiable sur un tunnel point à point, car le client doit à la fois envoyer des sollicitations et accepter la réponse. Certains clients de tunnel ne font ni l'un ni l'autre. Vérifiez ce que le client est prêt à accepter avant de décider que le serveur doit l'envoyer.
Le même préfixe doit être joignable depuis l'autre extrémité. Un client qui détient une adresse globale mais n'a aucun chemin de retour est configuré, pas connecté.
Les routes sont une promesse distincte
Même avec une adresse, le client doit savoir quelles destinations appartiennent au tunnel, et le serveur a besoin d'un chemin de retour pour ces destinations. Ce sont deux décisions prises à deux endroits. Un tunnel qui transporte tout le trafic IPv6 a besoin d'une route par défaut sur le client et d'une route de retour sur le serveur ; un tunnel divisé exige que les deux côtés s'accordent sur la même liste de préfixes. Quand ils ne sont pas d'accord, le trafic sort et ne revient jamais.
Écrivez la liste avant de configurer quoi que ce soit. Si le plan dit que seul le préfixe d'entreprise passe par le tunnel, le client ne doit pas avoir de route IPv6 par défaut, et le serveur ne doit pas en annoncer une.
L'intégration du client décide du reste
Certains clients de tunnel configurent IPv6 explicitement. Network Extension d'Apple, par exemple, prend une adresse, un préfixe et un ensemble de routes pour le tunnel, si bien qu'une application qui l'utilise n'attend pas une annonce de type Ethernet. D'autres comptent sur des annonces de routeur arrivant par la liaison. Les deux modèles sont légitimes et exigent un comportement de serveur différent, si bien que choisir le mauvais produit un client qui attend indéfiniment un message que personne n'envoie. Identifiez le modèle avant de modifier le serveur.
Un ancien nom d'interface comme ppp0 ne prouve rien sur la pile qui tourne aujourd'hui. Un client actuel peut utiliser une API de tunnel de paquets plutôt qu'une interface PPP, et supposer qu'il se comporte comme une connexion historique est la façon dont on casse une conception qui fonctionne. Demandez la version du client et la méthode de provisionnement, pas le nom de l'interface.
Écrivez le plan dont le client a besoin
Une description complète couvre trois choses : quelle adresse le client détient, quelles destinations le tunnel doit transporter et comment le réseau renvoie les réponses. Une adresse link-local ne répond à aucune d'elles, et une annonce acceptée ne répond qu'à une partie de l'une. Vérifiez chaque élément séparément au lieu d'accepter un indicateur vert. Puis notez quel mécanisme a fourni chaque réponse, car cet enregistrement transforme le prochain rapport IPv6 en une vérification de deux minutes.
Conservez l'enregistrement avec la documentation du service et mettez-le à jour quand le client change. Un plan qui était juste pour un client PPP peut être faux pour un client de tunnel de paquets sur le même service. Les quatre questions restent les mêmes ; seules les réponses bougent.