Fred: >As to Suresh's issue, I don't see it as necessary to check >self-generated addresses to be sure they do not encode the >ISATAP "magic number", since self-generated addresses cannot >be assigned on ISATAP interfaces, and ISATAP addresses >cannot be assigned on ordinary IPv6 interfaces. Hence, >there is no ambiguity and no need for a special registry. That makes the most sense so far.
So, that removes ISATAP addresses from consideration. It does not however leave the all-zero's interface-identifier as that has special meaning (see RFC 4291, 2.6.1. Required Anycast Address). If that is all, then draft-ietf-ipv6-privacy-addrs-v2-05.txt should state that instead of the vague "Compare the generated identifier against a list of reserved interface identifiers ...". The draft could retain that language, as long as it defined what this reserved list was. Leaving it unspecified just causes folks to wonder what the list might be -- hence my original suggestion for having it an IANA managed list. - Bernie -----Original Message----- From: Templin, Fred L [mailto:[EMAIL PROTECTED] Sent: Friday, March 30, 2007 6:22 PM To: Christian Huitema; Suresh Krishnan; Bernie Volz (volz) Cc: Alexandru Petrescu; ipv6@ietf.org Subject: RE: Reserved interface identifier registry To correct myself, we verified under Microsoft Windows Vista that the ISATAP interface sets the "u" bit to 1 when the node is configured with a public IPv4 address and sets the "u" bit to 0 when the node is configured with a private IPv4 address. Hence, there is no change to the text of RFC4214. As to Suresh's issue, I don't see it as necessary to check self-generated addresses to be sure they do not encode the ISATAP "magic number", since self-generated addresses cannot be assigned on ISATAP interfaces, and ISATAP addresses cannot be assigned on ordinary IPv6 interfaces. Hence, there is no ambiguity and no need for a special registry. Fred [EMAIL PROTECTED] > -----Original Message----- > From: Templin, Fred L > Sent: Wednesday, March 28, 2007 7:41 AM > To: Christian Huitema; Suresh Krishnan; Bernie Volz (volz) > Cc: Alexandru Petrescu; ipv6@ietf.org > Subject: RE: Reserved interface identifier registry > > > Fred explained that ISATAP identifiers should really use the > > global bit as well. > > Hmm; not exactly what I said, but in (RFC4214, Section 6.1), > what if we were to change: > > "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." > > to: > > "The "u" bit (universal/local) is set to 1 but the interface > identifier is only known to be unique within the site, i.e., > it may or may not be unique on a global basis." > > This would certainly ease some of the pressure Suresh may be > feeling, but would there be a backward-compatibility issue > for already-deployed implementations? (As long as the existing > implementationss treat the 'u' bit as "don't-care", there > should be no problem, right?) > > Thanks - Fred > [EMAIL PROTECTED] > > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
