RE: Reserved interface identifier registry

I think we concluded that this registry was not necessary?

I'm not sure what will happen to draft-ietf-ipv6-privacy-addrs-v2-05.txt
when it becomes an RFC. Hopefully some change will occur to bullet 4 in
sectin 3.2.1:

3.2.1.  When Stable Storage Is Present

...

   4.  Compare the generated identifier against a list of reserved
       interface identifiers and to those already assigned to an address
       on the local device.  In the event that an unacceptable
       identifier has been generated, the node MUST restart the process
       at step 1 above, using the right-most 64 bits of the MD5 digest
       obtained in step 2 in place of the history value in step 1. 

To remove this text about comparing against a list of reserved IIDs.
This was what caused my initial query as this draft doesn't indicate
what this list of reserved identifiers is.

- Bernie

-----Original Message-----
From: Pekka Savola [mailto:pekkas@netcore.fi] 
Sent: Wednesday, May 30, 2007 3:32 AM
To: Suresh Krishnan
Cc: ipv6@ietf.org
Subject: Re: Reserved interface identifier registry

On Tue, 20 Mar 2007, Suresh Krishnan wrote:
>  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. I have written a draft
regarding 
> this and I was wondering if the wg considers this to be useful work
worth 
> pursuing. I would also like to know if there are any other RFCs/drafts
which 
> depend on using specific IIDs.

I only now read draft-krishnan-ipv6-reserved-iids-00.txt.

I will note that the draft proposed establishing an IID registry, but 
AFAICS doesn't specify that these must be excluded from 
auto-configuration or other such functions.  Or is such "exclude IIDs 
listed in the registry" specification expected to happen in the 
future, in revised protocol specifications?

That was a main open issue I saw in the (short) draft.

It would also have been useful if there had been more text to give 
guidance to the designated expert on in which cases it would be OK to 
accept a registration.  As the draft cites 'exceptional 
circumstances', maybe a higher bar (e.g., IETF consensus or Standards 
action) would also be possible.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------