Technical Summary:
The IPv6 addressing architecture includes a unicast interface
identifier that is used in the creation of many IPv6 addresses.
Interface identifiers are formed by a variety of methods. This
document clarifies that the bits in an interface identifier have no
generic meaning and that the identifier should be treated as an
opaque value. In particular, RFC 4291 defines a method by which the
Universal and Group bits of an IEEE link-layer address are mapped
into an IPv6 unicast interface identifier. This document clarifies
that those two bits are significant only in interface identifiers
that are derived from an IEEE link-layer address, and updates RFC
4291 accordingly.
Working Group Summary:
This document is the product of the IPv6 WG. The final version
reflects strong WG consensus.
Document Quality:
In the 6man working group, the chairs do a detailed review
and also ask one or two volunteers (or hand picked experts) to
do a thorough review of documents before the are being
advanced to the IESG.
Fernando Gont performed a detailed review of the final version.
Personnel:
Ole Troan is the document Shepherd.
Brian Haberman is the Area Director.
RFC Editor Note
OLD:
This section describes clarifications to the IPv6 specifications that
result from the above discussion. Their aim is to reduce confusion
while retaining the useful aspects of the "u" and "g" bits in IIDs.
NEW:
This section describes clarifications to the IPv6 specifications that
result from the above discussion.
OLD:
In an IID, this bit is in position 6, i.e., position 70 in the
complete IPv6 address.
NEW:
In an IID, this bit is in position 6, i.e., position 70 in the
complete IPv6 address (when counting from 0).
OLD:
In an IID, this bit is in position 7, i.e., position 71 in the
complete IPv6 address.
NEW:
In an IID, this bit is in position 7, i.e., position 71 in the
complete IPv6 address(when counting from 0).