Jim and all,
Jim Bound wrote:
> This is a good technical question.
>
> > Yes excuse me, I did mean autoconfiguration. As I read
> >Thomas' draft the fix for the MAC privacy problem is not
> >addressed as a function of autoconfiguration. What part
> >did you see that does?
>
> From: draft-ietf-ipngwg-addrconf-privacy-00.txt
> The following text defines the adjuncts to stateless addrconf RFC 2462
> what would need to be done, and the modifications to RFC 2462 to resolve
> the issue at hand. On this list today and yesterday I was also hearing
> folks would want manual configuration too. Me too. As a third option.
> Having implemented addr conf I will say this is very doable and its a
> matter of the IETF working on the spec (which is in process) and
> wrapping this up.
I agree here and this is in part one method of addressing the
the privacy concerns. But I would strongly suggest for reasons
that I have already stated the the autoconfiguration include that the
privacy concerns be addressed as a default of the spec. If this
is done much of the problem with IPv6 in this area would be
adequately addressed. I also agree that a manual configuration too
be included as has been suggested by others, but be a second
priority to the autoconfiguration fix.
>
>
> So as I read the attached below the issue is addressed for address
> autoconfiguration.
>
> I would suggest we just move on to the technical work at hand and work
> this spec out in the working group.
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 3. Protocol Description
>
> The goal of this section is to define procedures that:
>
> 1) Result in a different interface identifier being generated at each
> system restart or attachment to a network.
>
> 2) Produce a sequence of interface identifiers that appear to be
> random in the sense that it is difficult for an outside observer
> to predict a future identifier based on a current one and it is
> difficult to determine previous identifiers knowing only the
> present one.
>
> 3.1. When Stable Storage is Present
>
> The following algorithm assumes the presence of a 64-bit "history
> value" that is used as input in generating an interface identifier.
> The very first time the system boots (i.e., out-of-the-box), any
> value can be used including all zeros. Whenever a new interface
> identifier is generated, its value is saved in the seed for the next
> iteration of the process.
>
> Section 5.3 of [ADDRCONF] describes the steps for generating a link-
> local address when an interface becomes enabled. This document
> modifies that step in the following way. Rather than use interface
> identifiers generated as described in [ADDRARCH], the identifier is
> generated as follows:
>
> 1) Take the history value from the previous iteration (or 0 if there
> is no previous value) and append to it the interface identifier
> generated as described in [ADDRARCH].
> 2) Compute the MD5 message digest [MD5] over the quantity created in
> step 1).
> 3) Take the left-most 64-bits of the MD5 digest and set bit 6 (the
> left-most bit is numbered 0) to zero. This creates an interface
> identifier with the universal/local bit indicating local
> significance only. Use the resultant identifier for generating
> addresses as outlined in [ADDRCONF]. That is, use the interface
> identifier to generate a link-local and other appropriate
> addresses.
> 4) Save the interface identifier created in step 3) in stable storage
> as the history value to be used in the next iteration of the
> algorithm.
>
> MD5 was chosen for convenience, not because of strict requirements.
> IPv6 nodes are already required to implement MD5 as part of IPsec
> [IPSEC], thus the code will already be present on IPv6 machines.
>
> 3.2. In The Absence of Stable Storage
>
> In the absence of stable storage, no history information will be
> available to generate a pseudo-random sequence of interface
> identifiers. Consequently, identifiers will need to be generated at
> random. A number of techniques might be appropriate. Consult [RANDOM]
> for suggestions on good sources for obtaining random numbers. Note
> that even though a machine may not have stable storage for storing
> the previously using interface identifier, they will in many cases
> have configuration information that differs from one machine to
> another (e.g., user identity, security keys, etc.). One approach to
> generating random interface identifiers in such cases is to use the
> configuration information to generate some data bits (which may be
> remain constant for the life of the machine, but will vary from one
> machine to another), append some random data and compute the MD5
> digest as before. The remaining details for generating addresses
> would be analogous to those of the previous section.
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> /jim
Regards,
--
Jeffrey A. Williams
Spokesman INEGroup (Over 95k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [EMAIL PROTECTED]
Contact Number: 972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
