Subject: Re: Reserved interface identifier registry

From: Pekka Savola <[email-masked]>
Date: Wed, 30 May 2007 10:32:08 +0300 (EEST)

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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 30 May 2007 10:40:22 -0400

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

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 30 May 2007 10:44:36 -0400

Hi Bernie,
   I will make the change to privacy-addrs in AUTH48.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 30 May 2007 10:56:28 -0400

Hi Pekka,

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?

Yes. This was the goal of the draft. To maintain a excluded IID list for 
both autoconf and stateful conf. But many people mentioned such a 
registry is not required. I am yet to be convinced.

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.

Sounds good. Actually, my goal was never but I thought it was too strong.

Thanks
Suresh