Significance of IPv6 Interface Identifiers
RFC 7136

[Ballot comment]
was:

So I'm 100% in favor of the goal if this draft however:

  Their aim is to reduce confusion
  while retaining the useful aspects of the "u" and "g" bits in IIDs.

If they're now opaque then their useful attributes is that they are two bits. the only way to know with any degree of certainty if an ip address is derived from a mac address if if you have an L2 adjacency with the device or have insight into how it was provisioned.

The text does not really mollify me with respect to retaining "useful" aspects of the u and g bits.

brain carpenter said in response:


  Yes, you're right; I think that phrase was written very early in the
  life of the draft, when it seemed like a reasonable statement. After
  several attempts at improving the sentence, I think the best solution
  is to delete it, so the start of Section 5 would simply be:

  This section describes clarifications to the IPv6 specifications that
  result from the above discussion.

    Brian

which I can live with.

[Ballot comment]
I have no objection to the publication of this draft.

Maybe it is just me, but it seems very strange to publish a Standards Track document, the substance of which seems to be to tell the reader that their *may* be a special meaning to two bits but they cannot  know for certain that this is the case. I understand that for procedural reasons the RFC needs to be published as ST, but perhaps the definitive statements should be in the normative text and the informational text should be an appendix.

I found the document very confusing to read, but given the expertise of the authors, shepherd, AD and reviewers, I conclude that the text correct, and the IPv6 address architecture is complex. Hopefully it is not yet too complex for those that need to deploy and configure IPv6.

[Ballot comment]
No objection to the publication, but let's speak about this one.

When you wrote about the "u/l" bit:

      In an IID, this bit is in position 6, i.e., position 70 in the
      complete IPv6 address.

You actually mean the 7th position because you start counting at 0. I guess that you have RFC 4291 appendix. A in mind:

  |0              1|1              3|3              4|4              6|
  |0              5|6              1|2              7|8              3|
  +----------------+----------------+----------------+----------------+
  |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
  +----------------+----------------+----------------+----------------+


Without knowing that you start counting at 0, this is a mistake.
Proposal (but feel free to develop your own text):

      In an IID, this bit is in the seventh from the left, i.e., position 70 in the
      complete IPv6 address, when starting counting at zero like in the figures in RFC 4291 appendix A.

Same remark for the "i/g" bit:

      In an IID, this bit is in position 7, i.e., position 71 in the
      complete IPv6 address.

NEW ADDITION TO THIS "NO OBJECTION", FOLLOWING AN EMAIL DISCUSSION WITH BRIAN:
>>> RFC 4291, section 2.5.1
>>> . Interface
>>> Identifiers
>>>      Interface identifiers in IPv6 unicast addresses are used to identify
>>>      interfaces on a link.  They are required to be unique within a subnet
>>>      prefix.  It is recommended that the same interface identifier not be
>>>      assigned to different nodes on a link.
>>> "it's _required _to be unique", so you're right.
>>> On the other hand, I see "It is _recommended _that the same interface
>>> identifier not be assigned to different nodes on a link "
>>> It seems to me that those 2 sentences contradict each other. I'm
>>> slightly confused....
> That 'recommended' does seem screwy,
Is this something you should be updating (in the sense OLD/NEW) in the draft?
It would make sense to me...

[Ballot discuss]
So I'm 100% in favor of the goal if this draft however:

  Their aim is to reduce confusion
  while retaining the useful aspects of the "u" and "g" bits in IIDs.

If they're now opaque then their useful attributes is that they are two bits. the only way to know with any degree of certainty if an ip address is derived from a mac address if if you have an L2 adjacency with the device or have insight into how it was provisioned.

The text does not really mollify me with respect to retaining "useful" aspects of the u and g bits.

[Ballot comment]
No objection to the publication, but let's speak about this one.

When you wrote about the "u/l" bit:

      In an IID, this bit is in position 6, i.e., position 70 in the
      complete IPv6 address.

You actually mean the 7th position because you start counting at 0. I guess that you have RFC 4291 appendix. A in mind:

  |0              1|1              3|3              4|4              6|
  |0              5|6              1|2              7|8              3|
  +----------------+----------------+----------------+----------------+
  |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
  +----------------+----------------+----------------+----------------+


Without knowing that you start counting at 0, this is a mistake.
Proposal (but feel free to develop your own text):

      In an IID, this bit is in the seventh from the left, i.e., position 70 in the
      complete IPv6 address, when starting counting at zero like in the figures in RFC 4291 appendix A.

Same remark for the "i/g" bit:

      In an IID, this bit is in position 7, i.e., position 71 in the
      complete IPv6 address.

[Ballot comment]
Just trying to get a couple of reviews in early:

1) For the changes to s2.5.1 of RFC 4291 in s5, should it be:

  "For all unicast addresses, except those that start with the binary
    value 000, Interface IDs are required to be 64 bits long. If derived
    from an IEEE MAC-layer address, they MUST be constructed in Modified
    EUI-64 format."

I.e., r/must/MUST?

IANA OK. Comments in tracker.
IANA Actions - YES

Upon approval of this document, we understand that we need to update
the registry "Reserved IPv6 Interface Identifiers registry" located
at:

http://www.iana.org/assignments/ipv6-interface-ids/

as follows:

Reference: [RFC5453][RFC-to-be]
Note:
  Full deployment of a new reserved IID value would require updates to
  IID generation code in every deployed IPv6 stack, so the technical
  justification for such a Standards Action would need to be extremely
  strong.

These are the only IANA Actions that need completion.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-6man-ug-05.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has some questions about the text of the IANA Considerations section
of this document.

Should the text in the IANA Considerations section of this document:

"Full deployment of a new reserved IID value would require updates to IID generation code in every deployed IPv6 stack, so the technical justification for such a Standards Action would need to be extremely strong."

be added to the Reserved IPv6 Interface Identifiers registry located at:

http://www.iana.org/assignments/ipv6-interface-ids/

?  Then, should the reference for this registry be updated to [RFC5453]
and [ RFC-to-be ]?

Other than the above questions, IANA understands that, upon approval of this document, there are no IANA Actions that need completion.  IANA requests that the IANA Considerations section of the document remain in place upon publication.


Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Significance of IPv6 Interface Identifiers) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Significance of IPv6 Interface Identifiers'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-11-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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
  meaning and that the entire 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 the process of deriving
  interface identifiers from an IEEE link-layer address, and updates
  RFC 4291 accordingly.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-ug/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-ug/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

This memo is intended for publication as Proposed Standard. It UPDATES
another Standards Track document (RFC 4291). This is reflected on the
title page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

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:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ole Troan is the document Shepherd. Brian Haberman is the Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has reviewed the final version of the document, as well
as detailed reviews during working group adoption and working group
last calls of the document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Eric Gray (the IEEE liaison) reviewed the document and also asked
for opinions from IEEE 802.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is strong WG consensus behind the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

There are no nits found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The document has been reviewed by the 6man WG.

(13) Have all references within this document been identified as
either normative or informative?

Yes


(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so,
list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

Yes. This document updates RFC 2460. This is mentioned in the header,
abstract and body of the text.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

All confirmed.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Ran nit-checker

All,
    I have completed my AD evaluation of draft-ietf-6man-ug.  I found
it to be well-written and to the point.  I only have a few comments on
the document.  Once these are resolved, I can start the IETF Last Call
on it.

1. ID-nits complains about three issues:

  * The updating of 4291 may require this draft to have the pre-RFC5378
boilerplate.  Given the formulation of this document, I don't believe we
need the pre-RFC5378 boilerplate.

  * Two lines exceed the 72-character limit.

  * Several references are out-dated.

2. Abstract

  * I cannot parse the phrase "have no generic meaning".  I think what
you want to say is that the bits are generic and the entire IID is a
single opaque value.

  * Similarly, the bits are not significant within the IID, they are
only significant during the formulation of the IID from the IEEE
link-layer address.

3. Section 5

  * The first sentence of the third paragraph could be clarified.  The
clause "need not treat the 'u' and 'g' bits in any special way" does not
necessarily agree with the MUST in the first part of the sentence. Would
it make more sense to change "need not treat" to "MUST NOT treat"?

Regards,
Brian

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

This memo is intended for publication as Proposed Standard. It UPDATES
another Standards Track document (RFC 4291). This is reflected on the
title page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

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:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ole Troan is the document Shepherd. Brian Haberman is the Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has reviewed the final version of the document, as well
as detailed reviews during working group adoption and working group
last calls of the document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Eric Gray (the IEEE liaison) reviewed the document and also asked
for opinions from IEEE 802.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is strong WG consensus behind the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

There are no nits found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The document has been reviewed by the 6man WG.

(13) Have all references within this document been identified as
either normative or informative?

Yes


(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so,
list these downward references to support the Area Director in the
Last Call procedure.

Yes, RFC5342.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

Yes. This document updates RFC 2460. This is mentioned in the header,
abstract and body of the text.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

All confirmed.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Ran nit-checker