12.1. Requesting router behavior

Le routeur demandeur utilise un message Request pour peupler les IA_PD avec des préfixes. Le routeur demandeur inclut une ou plusieurs options IA_PD dans le message Request. Le routeur délégant retourne ensuite les préfixes pour les IA_PD au routeur demandeur dans des options IA_PD dans un message Reply.

Le routeur demandeur inclut des options IA_PD dans tout message Renew ou Rebind envoyé par le routeur demandeur. L'option IA_PD inclut tous les préfixes que le routeur demandeur a actuellement associés à cet IA_PD.

Dans certaines circonstances, le routeur demandeur peut avoir besoin de vérification que le routeur délégant a toujours une liaison valide pour le routeur demandeur. Des exemples de moments où un routeur demandeur peut demander une telle vérification incluent:

• Le routeur demandeur redémarre.

• Le lien en amont du routeur demandeur fluctue.

• Le routeur demandeur est physiquement déconnecté d'une connexion filaire.

Si une telle vérification est nécessaire, le routeur demandeur DOIT initier un échange de messages Rebind/Reply comme décrit dans la section 18.1.4, "Creation and Transmission of Rebind Messages" de la RFC 3315, à l'exception que les paramètres de retransmission DEVRAIENT être fixés comme pour le message Confirm, décrit dans la section 18.1.2, "Creation and Transmission of Confirm Messages" de la RFC 3315. Le routeur demandeur inclut tous les IA_PD, avec les préfixes associés à ces IA_PD dans son message Rebind.

Chaque préfixe a des durées de vie valide et préférée dont les durées sont spécifiées dans l'option IA_PD Prefix pour ce préfixe. Le routeur demandeur utilise des messages Renew et Rebind pour demander l'extension des durées de vie d'un préfixe délégué.

Le routeur demandeur utilise un message Release pour retourner un préfixe délégué à un routeur délégant. Les préfixes à libérer DOIVENT être inclus dans les IA_PD.

Les types de message Confirm et Decline ne sont pas utilisés avec la délégation de préfixe.

À la réception d'un message Reply valide, pour chaque IA_PD, le routeur demandeur assigne un sous-réseau depuis chacun des préfixes délégués à chacun des liens auxquels les interfaces associées sont attachées, avec l'exception suivante: le routeur demandeur NE DOIT PAS assigner de préfixes délégués ou de sous-réseaux depuis le ou les préfixes délégués au lien par lequel il a reçu le message DHCP du routeur délégant.

Lorsqu'un routeur demandeur subdivise un préfixe délégué en sous-réseaux, il doit assigner des bits additionnels au préfixe pour générer des préfixes uniques et plus longs. Par exemple, si le routeur demandeur dans la Figure 1 se voyait déléguer 3FFE:FFFF:0::/48, il pourrait générer 3FFE:FFFF:0:1::/64 et 3FFE:FFFF:0:2::/64 pour l'assignation aux deux liens dans le réseau de l'abonné. Si le routeur demandeur se voyait déléguer 3FFE:FFFF:0::/48 et 3FFE:FFFF:5::/48, il pourrait assigner 3FFE:FFFF:0:1::/64 et 3FFE:FFFF:5:1::/64 à l'un des liens, et 3FFE:FFFF:0:2::/64 et 3FFE:FFFF:5:2::/64 pour l'assignation à l'autre lien.

Si le routeur demandeur assigne un préfixe délégué à un lien auquel le routeur est attaché et commence à envoyer des annonces de routeur pour le préfixe sur le lien, le routeur demandeur DOIT fixer la durée de vie valide dans ces annonces pour qu'elle ne soit pas postérieure à la durée de vie valide spécifiée dans l'option IA_PD Prefix. Un routeur demandeur PEUT utiliser la durée de vie préférée spécifiée dans l'option IA_PD Prefix.

La gestion des options Status Code dans les messages Reply reçus est décrite dans la section 18.1.8, "Receipt of Reply Messages" de la RFC 3315. Le code de statut NoPrefixAvail est géré de la même manière que le code de statut NoAddrsAvail.