Skip to main content

Reserved IPv6 Interface Identifiers
RFC 5453

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>, 
    6man mailing list <>, 
    6man chair <>
Subject: Protocol Action: 'Reserved IPv6 Interface Identifiers' 
         to Proposed Standard 

The IESG has approved the following document:

- 'Reserved IPv6 Interface Identifiers '
   <draft-ietf-6man-reserved-iids-04.txt> as a Proposed Standard

This document is the product of the IPv6 Maintenance Working Group. 

The IESG contact persons are Jari Arkko and Mark Townsley.

A URL of this Internet-Draft is:

Ballot Text

Technical Summary

  Interface Identifiers in IPv6 unicast addresses are used
  to identify interfaces on a link.  They are required to be
  unique within a subnet.  Several RFCs have specified
  interface identifiers or identifier ranges that have a
  special meaning attached to them.  An IPv6 node
  autoconfiguring an interface identifier in these ranges
  will encounter unexpected consequences.  Since there is no
  centralized repository for such reserved identifiers, this
  document aims to create one.

Working Group Summary

  The 6MAN working group has done extensive reviews of this 
  document and it reflects the consensus of the working group.

Document Quality

  This document has been reviewed by numerous members of the mailing list and by the 6MAN WG chairs.

  Brian Haberman is the Document Shepherd, and Jari Arkko is
  the responsible Area Director.

RFC Editor Note

  Make this change in Appendix A:

  The following RFCs that generate interface identifiers need to be
  updated if they wish to avoid conflicts with the reserved interface
  identifier ranges.
  Implementations of the following RFCs need to be aware of the 
  reserved interface identifier ranges when they allocate new
  addresses. Future revisions of these RFCs should ensure that
  this is either already sufficiently clear or that the text
  is amended to take this into account.

RFC Editor Note