Subject: Re: Reserved interface identifier registry

From: Tim Enos <[email-masked]>
Date: Wed, 21 Mar 2007 10:43:46 -0500 (CDT)

[snip]

Hi Suresh/all,

>Hi Folks,
>   Some RFCs (I know of at least 2, RFC2526 and RFC4214) reserve a set 
>of interface identifiers on all prefixes. These identifiers need to be 
>excluded when a node autoconfigures an address. This problem occurs with 
>privacy addresses but is equally applicable to other address assigment 
>methods like dhcpv6, cga etc. As Bernie suggested in a mail it would be 
>good to maintain a list of such identifiers. This is possible by either 
>listing the currently assigned IIDs in a document, or by creating an 
>IANA registry. The former is useful if there will be no such allocations 
>in the future and the later is useful if there will be future 
>allocations.

IMHO we can't reasonably and conclusively say there will be no future allocations. My vote is for creating an IANA registry for currently assigned IIDs.

I have written a draft regarding this and I was wondering 
>if the wg considers this to be useful work worth pursuing.

What is the name of/link to the draft?

I would also 
>like to know if there are any other RFCs/drafts which depend on using 
>specific IIDs.

I'd be happy to be one of the folks who researches this. Also, given we don't presently have the exhaustive IID assignment list, it seems there may presently be some overlapping and/or (mutually) exclusive IID assignments.

IMO it would be good for authors to be conditioned to reference such an IANA registry (and to have to instruct the IANA to make modifications/additions) each time they wrote a draft that required the use of (theretofore unused) IID space. The one-stop shopping would be nice.

Best Regards,

Tim Enos
Rom 8:28

>
>Thanks
>Suresh
>
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 28 Mar 2007 15:15:09 -0400

Also, the impact of assuming this individual/group bit exists is the
loss of 1 bit (so the "randomly" generated value only has 62 bits of
uniqueness rather than 63 bits). While that cuts the number of values in
half, there is still plenty of randomness.

I do think answering this question about "local" link identifiers and
whether the individual/group bit applies is important and should be
resolved because it may impact future assignments for special purpose
identifiers.

- Bernie

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Wednesday, March 28, 2007 2:28 PM
To: 'Suresh Krishnan'
Cc: [email-masked]
Subject: RE: Reserved interface identifier registry

Well, my interpretation is that EUI-64s always have the universal/local
bit set to universal. And, non-EUI-64's have the universal/local bit
"set" to local.  For local ones, I assume that the 'c' and 'm' bits are
"anything goes". The question then is whether the individual/group bit
applies.

If one looks at the anycast addresses, those are group (as well as
local). So, that seems to imply that this carries over.

But, the following appendix section:

   Links with Other Kinds of Identifiers

   There are a number of types of links that have link-layer interface
   identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs.  Examples
   include LocalTalk and Arcnet.  The method to create a Modified EUI-64
   format identifier is to take the link identifier (e.g., the LocalTalk
   8-bit node identifier) and zero fill it to the left.  For example, a
   LocalTalk 8-bit node identifier of hexadecimal value 0x4F results in
   the following interface identifier:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
   +----------------+----------------+----------------+----------------+

   Note that this results in the universal/local bit set to "0" to
   indicate local scope.

Does not mention the individual/group bit, just the universal/local.

So, it is a bit unclear.

- Bernie

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2007 2:17 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: Reserved interface identifier registry

Hi Bernie,

Bernie Volz (volz) wrote:
> 4291 does mention it in Appendix A:
> 
>    where "c" is the bits of the assigned company_id, "0" is the value
of
>    the universal/local bit to indicate universal scope, "g" is
>    individual/group bit, and "m" is the bits of the manufacturer-
>    selected extension identifier.  The IPv6 interface identifier would
>    be of the form:
> 
>    |0              1|1              3|3              4|4
6|
>    |0              5|6              1|2              7|8
3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
> 
>    The only change is inverting the value of the universal/local bit.

It mentions what the format of the EUI-64 is. Not what these bits mean 
in the IID. My take on this is that the format of the EUI-64 has nothing

whatsoever to do with the format of the IID. If this were true we need 
to get OUIs assigned by IEEE (The 'c' bits in the figure) for each of 
the random IID generation techniques. Do you agree?

Cheers
Suresh