Skip to main content

13. IANA Considerations

This section describes the IANA (Internet Assigned Numbers Authority) registrations and considerations related to Neighbor Discovery for IPv6.

13.1. ICMPv6 Type and Code Registrations​

Neighbor Discovery uses several ICMPv6 message types that have been registered with IANA. The following ICMPv6 types are defined in this specification:

ICMPv6 TypeNameReference
133Router SolicitationRFC 4861, Section 4.1
134Router AdvertisementRFC 4861, Section 4.2
135Neighbor SolicitationRFC 4861, Section 4.3
136Neighbor AdvertisementRFC 4861, Section 4.4
137Redirect MessageRFC 4861, Section 4.5

All of these message types use Code 0, and no other Code values are currently defined for these types.

13.2. Neighbor Discovery Option Type Registry​

IANA maintains a registry for Neighbor Discovery Option Types. The following option types are defined in this specification:

Option TypeNameReference
1Source Link-Layer AddressRFC 4861, Section 4.6.1
2Target Link-Layer AddressRFC 4861, Section 4.6.1
3Prefix InformationRFC 4861, Section 4.6.2
4Redirected HeaderRFC 4861, Section 4.6.3
5MTURFC 4861, Section 4.6.4

13.2.1. Registration Procedure​

New Neighbor Discovery Option Types are allocated using the following procedure:

  • Values 0-255: IETF Review or IESG Approval required (as defined in RFC 8126)
  • New options MUST be documented in an RFC or other permanent, publicly available reference
  • The registration MUST include:
    • Option Type value
    • Option Name
    • Brief description of the option
    • Reference to the defining document

13.2.2. Option Type Format​

Option Type values are 8-bit identifiers. The high-order two bits of the Option Type field are used to specify the action to be taken if the option type is not recognized:

  • 00: Skip this option and continue processing the message
  • 01: Discard the message
  • 10: Discard the message and send an ICMP Parameter Problem message
  • 11: Discard the message and send an ICMP Parameter Problem message only if the destination address is not a multicast address

This encoding allows for flexible handling of unknown options and enables smooth deployment of new option types.

13.3. IPv6 Neighbor Discovery Protocol Constants​

While not directly managed by IANA, this specification defines several protocol constants (documented in Section 10) that implementers MUST use. These constants include timing values, retry limits, and other parameters essential for interoperability.

13.4. Router Advertisement Flags​

IANA maintains a registry for Router Advertisement flags. The following flags are defined in this specification:

BitFlag NameReference
0M (Managed Address Configuration)RFC 4861, Section 4.2
1O (Other Configuration)RFC 4861, Section 4.2
2-7ReservedRFC 4861

Additional flags may be defined in future specifications following IETF Review procedures.

13.5. Prefix Information Option Flags​

IANA maintains a registry for Prefix Information Option flags. The following flags are defined in this specification:

BitFlag NameReference
0L (On-Link)RFC 4861, Section 4.6.2
1A (Autonomous Address Configuration)RFC 4861, Section 4.6.2
2R (Router Address)RFC 6275
3-7ReservedRFC 4861

Note: The R flag was added by RFC 6275 (Mobile IPv6) and is included here for completeness.

13.6. Neighbor Advertisement Flags​

IANA maintains a registry for Neighbor Advertisement flags. The following flags are defined in this specification:

BitFlag NameReference
0R (Router)RFC 4861, Section 4.4
1S (Solicited)RFC 4861, Section 4.4
2O (Override)RFC 4861, Section 4.4
3-31ReservedRFC 4861

13.7. Updates to Previous Registrations​

This document (RFC 4861) obsoletes RFC 2461. All IANA registrations that referenced RFC 2461 have been updated to reference RFC 4861 instead.

13.8. Considerations for Future Extensions​

When defining new Neighbor Discovery messages, options, or flags:

  1. Backward Compatibility: Ensure that new features can coexist with existing implementations. Unknown options MUST be silently ignored as specified in Section 9.

  2. Security Implications: Consider how new features interact with security mechanisms such as SEcure Neighbor Discovery (SEND) [RFC3971].

  3. Documentation Requirements: Fully document the new feature in an RFC or other permanent, publicly available reference.

  4. IANA Registration: Follow proper IANA registration procedures as specified in RFC 8126.

  5. Implementation Experience: When possible, gain implementation and deployment experience before standardization.

13.9. References to IANA Registries​

Current IANA registries related to Neighbor Discovery can be found at:

Implementers and protocol designers should consult these registries for the most up-to-date information on registered values.

Last updated on