Significance of IPv6 Interface Identifiers
draft-ietf-6man-ug-06

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
>>> <http://tools.ietf.org/search/rfc4291#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...

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.

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?

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.