Then perhaps this should be mentioned in
draft-ietf-ipv6-privacy-addrs-v2-05.txt?
A randomized interface identifier is created as follows:
1. Take the history value from the previous iteration of this
algorithm (or a random value 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
the previous step.
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.
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.
Instead of step 4, perhaps step 4 (or as part of 3) should state that the
individual/group bit (bit 7) should be set to 0 to indiciate individual (unless
a group identifier were being generated, which I don't think is the point of
this draft). There is no mention of this bit in the document.
I'm not sure I fully understand Fred's statements with respect to ISATAP, but
if these are not an issue then that's great.
- Bernie
-----Original Message-----
From: Christian Huitema [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 27, 2007 7:56 PM
To: Suresh Krishnan; Bernie Volz (volz)
Cc: Alexandru Petrescu; [email protected]
Subject: RE: Reserved interface identifier registry
> Hi Folks,
> I am attaching the draft I wrote regarding this. Can you please
> comment.
>
> Thanks
> Suresh
>
> Bernie Volz (volz) wrote:
> > Correct. That is NOT the issue. 3041 and 3041 bis use "randomly"
> > generated identifiers that are "local" (not "global" as mac-derived
> > identifiers are) and there are some RFCs that RESERVE certain ranges
> > within this "local" space. We need some place to document that list
> of
> > reserved ranges so that a "randomly" generated identifiers don't use
> > those reserved ranges. Any future assignment of reserved local
> > identifiers always run the risk of having existing implementations
> > generate identifiers that may conflict.
Fred explained that ISATAP identifiers should really use the global bit as well.
As for anycast and multicast, these addresses supposedly set the "group" bit in
the identifiers -- and if they don't they really should, since the L2
transmission is multicast. Setting the G bit differentiates these addresses
from RFC3041 addresses.
I don't think that we have a real problem, and I believe that an additional
registry would do more harm than good. It would create an avenue for groups to
reserve more identifiers, in the naïve belief that implementations would
magically be updated to avoid these numbers. And it would create an extra
burden for implementers. Groups that want to reserve identifiers should really
use the IEEE 802 processes.
-- Christian Huitema
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
