In the case of RFC4214 at least, I'm not so sure now that there needs to be a reserved local range. From Section 6.1, the text:
"When the IPv4 address is known to be globally unique, the "u" bit (universal/local) is set to 1; otherwise, the "u" bit is set to 0. "g" is the individual/group bit, and "m" are the bits of the IPv4 address." But, I think now that we have sufficient operational experience it could be said that this text is unnecessary and unnecessarily causing us to keep a registry in the IANA. Reason being is that ISATAP will never cross NATs, and so it doesn't matter whether the IPv4 addresses are privacy addresses, global addresses or some mix of both because all nodes on the ISATAP link will be in the same site by definition. So, as long as the document states clearly that ISATAP interfaces MUST assign addresses of the form specified in section 6 (and no other types of addresses) I don't see the need to maintain an IANA registry. Fred [EMAIL PROTECTED] > -----Original Message----- > From: Bernie Volz (volz) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 27, 2007 6:31 AM > To: Christian Huitema; Suresh Krishnan > Cc: Alexandru Petrescu; ipv6@ietf.org > Subject: RE: Reserved interface identifier registry > > 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. > > - Bernie > > -----Original Message----- > From: Christian Huitema [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 27, 2007 12:38 AM > To: Suresh Krishnan > Cc: Alexandru Petrescu; ipv6@ietf.org > Subject: RE: Reserved interface identifier registry > > > Not really. You are assuming here that all IIDs are > generated from MAC > > addresses. IIDs can be generated using other methods like > CGA, Privacy > > Addresses etc. Hence reserving a range of MACs/OUIs is not > sufficient. > > Actually, the non Mac derived identifier include a bit that indicate > that "this is not a reserved value", and thus don't conflict with > MAC-derived identifiers. > > -- Christian Huitema > > > > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
