Quand un FAI modifie la configuration de son réseau
IPv6, les routeurs chez les clients finaux,
les CPE,
ne retransmettent pas toujours rapidement ce changement, ce qui mène
parfois à des problèmes de connectivité. Ce RFC décrit ce que doivent faire ces CPE
pour minimiser les conséquence négatives d'une rénumérotation d'un
réseau.
Le problème est documenté dans le : par exemple, lorsqu'un routeur chez M. Toutlemonde
(une « box ») redémarre et
« oublie » sa configuration réseau précédente, si elle a changé chez
le FAI entretemps, les machines du réseau local de M. Toutlemonde
risquent de continuer à utiliser pendant un certain une ancienne
configuration, désormais invalide. Comment éviter cela ?
Notre RFC se
penche surtout sur le cas où le routeur de M. Toutlemonde a appris
son préfixe IPv6 depuis le FAI via la
délégation de préfixe DHCP du , et
qu'il retransmet l'information sur ce préfixe dans le réseau local
avec le SLAAC du (via les RA, Router
Advertisements, ) ou bien
DHCP. Les machines terminales sur le réseau local peuvent aussi agir
(ce sera dans un futur RFC) mais
l'actuel RFC ne concerne que les routeurs. Il consiste en une série
d'exigences auxquelles doivent se prêter les routeurs, exigences qui
s'ajoutent à celles déjà présentes dans le ou bien qui modifient des exigences de ce .
Beaucoup de ces exigences nécessitent un mécanisme de stockage
d'informations sur le routeur, stockage qui doit survivre aux
redémarrages, ce qui ne sera pas évident pour tous les
routeurs. Ainsi, le RFC demande que, du côté WAN, le routeur utilise toujours le même
identificateur (IAID, Identity Association
IDentifier, , section 4.2)
en DHCP (pour essayer de garder le même préfixe). Certains routeurs
choisissent apparemment l'IAID au hasard à chaque démarrage, ce qui
leur obtient un nouveau préfixe. Il vaut mieux le garder, mais cela
nécessite qu'il puisse être stocké et mémorisé même en cas de
redémarrage. Comme tous les routeurs n'ont pas de mécanisme de
stockage stable, les exigences du RFC sont exprimées (dans le
langage du ) par un
SHOULD et pas un MUST.
Autre exigence, qui relève du bon sens, le routeur ne doit pas,
lorsqu'il utilise un préfixe du côté LAN (le réseau local), utiliser une durée de vie
plus longue (options Preferred Lifetime et
Valid Lifetime du message d'information sur le
préfixe envoyé par le routeur, ,
section 4.6.2) que celle qu'il a lui-même appris en DHCP côté
WAN. On ne doit pas promettre ce qu'on ne peut pas tenir, la durée
du bail DHCP s'impose au routeur et aux annonces qu'il fait sur le
réseau local.
Enfin, le routeur ne doit pas, au redémarrage, envoyer
systématiquement un abandon du préfixe appris en DHCP (message DHCP
RELEASE). Certains routeurs font apparemment
cela, ce qui risque de déclencher une renumérotation brutale ().
Lorsque le préfixe change, le routeur devrait aussi signaler cela
sur le réseau local. Là encore, cela impose une mémoire, un stockage
stable. Il doit se souvenir de ce qu'il a reçu, et annoncé,
précédemment, pour pouvoir annoncer sur le réseau local que ces
anciens préfixes ne doivent plus être utilisés (cela se fait en
annonçant ces préfixes, mais avec une durée de vie nulle). Dans un
monde idéal, le routeur sera prévenu des changements de préfixe
parce que le FAI réduira la durée de vie de ses baux DHCP,
permettant un remplacement ordonné d'un préfixe par un autre. Dans
la réalité, on a parfois des renumérotations brutales, sans préavis
(). Le routeur doit donc également
gérer ces cas.