9. Extensibilité - Traitement des Options (Extensibility - Option Processing)

Le protocole Neighbor Discovery est conçu pour être extensible par l'ajout de nouvelles options. Cette section décrit comment les nœuds traitent les options dans les messages Neighbor Discovery reçus afin d'assurer que les extensions futures puissent coexister avec les implémentations actuelles.

9.1. Principes Généraux (General Principles)

Pour garantir la compatibilité ascendante et l'extensibilité future :

• Options Non Reconnues (Unrecognized Options) : Tous les nœuds DOIVENT (MUST) ignorer silencieusement toute option qu'ils ne reconnaissent pas dans les paquets Neighbor Discovery reçus et continuer le traitement du paquet. Cela permet de définir de nouvelles options à l'avenir sans casser les implémentations existantes.

• Options Multiples (Multiple Options) : Les options peuvent apparaître plusieurs fois dans le même message. Les nœuds DOIVENT (MUST) être préparés à gérer ce cas de manière appropriée.

• Ordre des Options (Option Order) : L'ordre dans lequel les options apparaissent dans un message n'est généralement pas significatif, sauf indication explicite pour des types d'options particuliers.

• Remplissage (Padding) : Les options doivent être remplies si nécessaire pour s'assurer qu'elles se terminent sur leurs limites naturelles de 64 bits.

9.2. Règles de Traitement (Processing Rules)

Lors du traitement d'un message Neighbor Discovery contenant des options :

1. Analyser Toutes les Options (Parse All Options) : Le nœud DOIT (MUST) analyser toutes les options du message, même si certaines ne sont pas reconnues.

2. Ignorer les Options Inconnues (Ignore Unknown Options) : Si une option n'est pas reconnue (sur la base de son champ Type), le nœud DOIT (MUST) l'ignorer et continuer le traitement des options suivantes et du message lui-même.

3. Valider les Options Connues (Validate Known Options) : Pour les options reconnues, le nœud DOIT (MUST) valider l'option selon les règles spécifiées pour ce type d'option. Si une option échoue à la validation (par exemple, longueur incorrecte, valeurs de champ invalides), le comportement dépend du type d'option spécifique et du type de message.

4. Continuer le Traitement (Continue Processing) : Même si une ou plusieurs options sont invalides ou non reconnues, le nœud DEVRAIT (SHOULD) continuer le traitement du message et de toutes les options valides restantes, sauf si la spécification pour un type de message ou d'option particulier l'exige autrement.

9.3. Exigences du Format d'Option (Option Format Requirements)

Toutes les nouvelles options définies pour Neighbor Discovery DOIVENT (MUST) suivre le format d'option général spécifié dans la section 4.6, avec un champ Type et Length. Le champ Length est spécifié en unités de 8 octets.

Lors de la définition de nouvelles options, les concepteurs de protocole DEVRAIENT (SHOULD) :

• S'assurer que l'option peut être ignorée en toute sécurité par les nœuds qui ne l'implémentent pas, sans causer de problèmes opérationnels.
• Considérer l'impact sur la taille du message et le MTU du lien.
• Spécifier des règles de validation claires pour l'option.

9.4. Extensions Futures (Future Extensions)

Les modifications futures rétrocompatibles du protocole Neighbor Discovery peuvent :

• Définir de nouveaux types d'options
• Spécifier l'utilisation des champs actuellement Réservés dans les formats de message
• Définir de nouveaux bits de drapeau dans les messages existants (en comprenant que les drapeaux non reconnus sont ignorés)

Les modifications non rétrocompatibles nécessiteraient la définition de nouveaux types de messages (utilisant des valeurs ICMP Type ou Code différentes) ou la définition d'une nouvelle version du protocole.

9.5. Considérations d'Implémentation (Implementation Considerations)

Les implémentations DEVRAIENT (SHOULD) :

• Être conçues pour accueillir facilement de nouveaux types d'options sans nécessiter de modifications majeures du code.
• Journaliser ou fournir des informations de diagnostic sur les options non reconnues pour faciliter le débogage et le déploiement futur du protocole.
• Considérer les implications de sécurité lors du traitement des options, en particulier celles qui pourraient affecter les décisions de routage ou les entrées de cache.

9.6. Sécurité et Extensibilité (Security and Extensibility)

Le mécanisme d'extensibilité ne fournit pas intrinsèquement de sécurité. Les nouvelles options peuvent introduire de nouvelles vulnérabilités de sécurité si elles ne sont pas soigneusement conçues. Les concepteurs de protocole définissant de nouvelles options DEVRAIENT (SHOULD) :

• Considérer comment l'option interagit avec Secure Neighbor Discovery (SEND) [RFC3971].
• Analyser les attaques potentielles qui pourraient exploiter la nouvelle option.
• Documenter les considérations de sécurité spécifiques à la nouvelle option.

Les implémentations DEVRAIENT (SHOULD) fournir des mécanismes pour activer ou désactiver sélectivement le support de types d'options spécifiques en fonction de la politique de sécurité locale.

---