Difference between revisions of "Les en-têtes de mobilité"

From Livre IPv6

 
(<div id="format">Format général du paquet</div>)
Line 13: Line 13:
 
{|
 
{|
 
|+      Type des en-têtes de mobilité
 
|+      Type des en-têtes de mobilité
| 0 | Demande de rafraîchissement émise par le n?ud correspondant
+
|- style="background:silver"
 +
| 0 | Demande de rafraîchissement émise par le noeud correspondant
 
|-
 
|-
 
| 1 | Initialisation de test d'adresse mère (HoTI)
 
| 1 | Initialisation de test d'adresse mère (HoTI)
|-
+
|-style="background:silver"
 
| 2 | Initialisation de test d'adresse temporaire (CoTI)
 
| 2 | Initialisation de test d'adresse temporaire (CoTI)
 
|-
 
|-
 
| 3 | Test d'adresse mère (HoT)
 
| 3 | Test d'adresse mère (HoT)
|-
+
|-style="background:silver"
 
| 4 | Test d'adresse temporaire (CoT)
 
| 4 | Test d'adresse temporaire (CoT)
 
|-
 
|-
 
| 5 | Mise à jour d'association (émise depuis le noeud mobile)
 
| 5 | Mise à jour d'association (émise depuis le noeud mobile)
|-
+
|-style="background:silver"
 
| 6 | Acquittement de mise à jour d'association
 
| 6 | Acquittement de mise à jour d'association
 
|-
 
|-

Revision as of 18:55, 4 December 2005

Format général du paquet

Nous avons vu que les en-têtes de mobilité sont utilisés pour transporter la signalisation de la gestion des associations de mobilité entre le noeud mobile, son agent mère et le noeud correspondant.

Un en-tête de mobilité ne doit jamais être utilisé en même temps qu'un en-tête de routage de type 2, excepté dans le seul cas du transport d'un acquittement d'une demande de BU. Il ne doit jamais non plus être utilisé en même temps qu'une extension de destination, sauf dans certains cas de Binding Update avec l'agent mère ainsi qu'avec des n?uds correspondants déjà identifiés.

Le format général d'un en-tête de mobilité est donné See Format de l'extension de mobilité :

  • Le champ en-tête suivant est pris dans le même espace de numérotation que les en-têtes d'extension d'IPv6 (cf. See Valeurs du champ en-tête suivant, See Valeurs du champ en-tête suivant). Dans le cas de la signalisation de mobilité, il doit valoir 59 (pas d'en-tête suivant).
  • Le champ longueur de l'en-tête, en octets, ne prend pas en compte les 8 premiers octets de l'en-tête.
  • Le champ type d'en-tête décrit les messages de signalisation donné au See Type des en-têtes de mobilité.
Type des en-têtes de mobilité
Demande de rafraîchissement émise par le noeud correspondant
Initialisation de test d'adresse mère (HoTI)
Initialisation de test d'adresse temporaire (CoTI)
Test d'adresse mère (HoT)
Test d'adresse temporaire (CoT)
Mise à jour d'association (émise depuis le noeud mobile)
Acquittement de mise à jour d'association
Erreur de mise à jour d'association

La structure et la longueur du message varient en fonction du numéro de l'en-tête. De plus, MIPv6 définit également des options de mobilité associées à ces messages. Comme la longueur des messages associés à chaque numéro d'en-tête est connue, la présence d'une option est déduite d'une longueur de l'en-tête plus grande que ce qui est suffisant pour le message. Elle se trouve forcément à la suite du message.

Comme toutes les en-tête IPv6, ces en-têtes de mobilité doivent être alignés sur des frontières de 8 octets. Des champs réservés seront éventuellement insérés pour respecter cette contrainte. Un n?ud ne sachant pas interpréter une option doit l'ignorer. Actuellement MIPv6 ne définit d'option que pour les messages de BU (type 5) et leur acquittement (type 6). Format des messages et options des différents types d'en-têtes

La demande de rafraîchissement d'association ne requiert aucune information spécifique. Le message est vide, il n'y a pas d'option. (cf. See Format de l'extension de mobilité rafraîchissement d'association).

Les messages HoTI, CoTI ne contiennent que le nombre aléatoire émis par le n?ud mobile. Il ne contient pas d'option. (cf. See Format de l'extension de mobilité HoTI ou CoTI).

Les messages HoT, CoT contiennent, l'index du nombre aléatoire (nonce) choisi par le n?ud correspondant, le nombre aléatoire émis par le n?ud mobile (cookie), (pour le test home address ou care-of address) et le jeton chiffré (keygen token) émis par le n?ud correspondant. Il ne contient pas d'option (cf. See Format de l'extension de mobilité HoT ou CoT).

Les messages de notification de mise à jour d'association, émis par le n?ud mobile, peuvent contenir des options mobiles. Si elles ne sont pas présentes, le paquet doit se terminer par 4 octets de bourrage. (cf. See Format de l'extension de mobilité mise à jour d'association)

Les options possibles sont :

  • Les données d'autorisation de mise à jour d'association. L'option est obligatoire pour les mises à jour émises vers le n?ud correspondant puisqu'elles ne sont pas protégées par IPsec.
  • L'indice du "nonce" choisi par le n?ud correspondant.
  • Une "care-of address" alternative.

Les message d'acquittement de mise à jour d'association peut contenir des options mobiles. Si elles ne sont pas présentes, le paquet doit être terminé par 4 octets de bourrage. (cf. See Format de l'extension de mobilité acquittement de mise à jour d'association) :

  • Une valeur du champ statut inférieure à 128 indique un acquittement, et une valeur supérieure un rejet. Le motif du rejet est codé par la valeur du statut.
  • Le bit K = 1 indique que l'association de sécurité IPsec suivra les mouvements du n?ud mobile. Le n?ud correspondant doit le positionner à 0.
  • Les options possibles sont :
    • Les données d'autorisation de mise à jour d'association.
    • Les informations de fréquence de rafraîchissement des associations.

Les messages d'erreur de mise à jour d'association contiennent un statut sur 8 bits codant l'erreur, ainsi que la home address de la mise à jour en erreur pour le cas où le noeud mobile aurait établi plusieurs associations avec le n?ud correspondant (cf. See Format de l'extension de mobilité HoT ou CoT).

Personal tools