Skip to main content

9. Extensibility - Option Processing

The Neighbor Discovery protocol is designed to be extensible through the addition of new options. This section describes how nodes process options in received Neighbor Discovery messages to ensure that future extensions can coexist with current implementations.

9.1. General Principles​

To ensure backward compatibility and forward extensibility:

  • Unrecognized Options: All nodes MUST (MUST) silently ignore any options they do not recognize in received Neighbor Discovery packets and continue processing the packet. This allows new options to be defined in the future without breaking existing implementations.

  • Multiple Options: Options may appear multiple times in the same message. Nodes MUST (MUST) be prepared to handle this case appropriately.

  • Option Order: The order in which options appear in a message is generally not significant, unless explicitly specified for particular option types.

  • Padding: Options should be padded when necessary to ensure that they end on their natural 64-bit boundaries.

9.2. Processing Rules​

When processing a Neighbor Discovery message containing options:

  1. Parse All Options: The node MUST (MUST) parse through all options in the message, even if some are not recognized.

  2. Ignore Unknown Options: If an option is not recognized (based on its Type field), the node MUST (MUST) ignore it and continue processing subsequent options and the message itself.

  3. Validate Known Options: For recognized options, the node MUST (MUST) validate the option according to the rules specified for that option type. If an option fails validation (e.g., incorrect length, invalid field values), the behavior depends on the specific option type and message type.

  4. Continue Processing: Even if one or more options are invalid or unrecognized, the node SHOULD (SHOULD) continue processing the message and any remaining valid options, unless the specification for a particular message type or option requires otherwise.

9.3. Option Format Requirements​

All new options defined for Neighbor Discovery MUST (MUST) follow the general option format specified in Section 4.6, with a Type and Length field. The Length field is specified in units of 8 octets.

When defining new options, protocol designers SHOULD (SHOULD):

  • Ensure that the option can be safely ignored by nodes that do not implement it, without causing operational problems.
  • Consider the impact on message size and link MTU.
  • Specify clear validation rules for the option.

9.4. Future Extensions​

Future backward-compatible changes to the Neighbor Discovery protocol may:

  • Define new option types
  • Specify the use of currently Reserved fields in message formats
  • Define new flag bits in existing messages (with the understanding that unrecognized flags are ignored)

Backward-incompatible changes would require defining new message types (using different ICMP Type or Code values) or defining a new version of the protocol.

9.5. Implementation Considerations​

Implementations SHOULD (SHOULD):

  • Be designed to easily accommodate new option types without requiring major code changes.
  • Log or provide diagnostic information about unrecognized options to aid in debugging and future protocol deployment.
  • Consider security implications when processing options, particularly those that could affect routing decisions or cache entries.

9.6. Security and Extensibility​

The extensibility mechanism does not inherently provide security. New options may introduce new security vulnerabilities if not carefully designed. Protocol designers defining new options SHOULD (SHOULD):

  • Consider how the option interacts with Secure Neighbor Discovery (SEND) [RFC3971].
  • Analyze potential attacks that could exploit the new option.
  • Document security considerations specific to the new option.

Implementations SHOULD (SHOULD) provide mechanisms to selectively enable or disable support for specific option types based on local security policy.

Last updated on