Le 2013-02-02 à 14:45, Ray Hunter <[email protected]> a écrit : ... >> In any case, and more important in my understanding, this doesn't change >> that any IID having u=1 can never conflict with IEEE-derived IIDs, be they >> duplicated or not. A clarification on this would IMHO be useful. > > I have a problem with any assumption that u=1 => global uniqueness, or > u=1 => IEEE EUI64 with IEEE administered OUI. > > Carefully reading RFC4291 I come up with the following: > > Quote: "Modified EUI-64 format-based interface identifiers may have > universal > scope when derived from a universal token (e.g., IEEE 802 48-bit MAC > or IEEE EUI-64 identifiers [EUI64])" > > Note the "may" and note the "e.g."
This is OK because RFC 4291 says "For ALL UNICAST ADDRESSES, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format" (upper-cases added). This implies that IIDs that have u=0 belong to those that have the "Modified EUI-64 format". > > Quote: "EUI64 *format*" > > Note the complete absence of text like "when u=1, the IID SHOULD/MUST be > formed from an IEEE EUI64, including a globally unique OUI portion > administered by the IEEE." The point is that it is the opposite that is said: EUI-64 derived IIDs are NOT the only ones having the "Modified EUI-64 format" (see above). > I therefore openly question any assumptions regarding the IEEE as being > defined as the sole and exclusive source of "universal tokens" in the > IPv6 addressing architecture. Agreement on this. > If another standards body built a link technology based on EUI64 > *format* identifiers, but with their own OUI administration, that should > never be a problem for IPv6, because RFC4291 only requires IID's to be > "unique within a subnet prefix." They are not required to be globally > unique across all link technologies. This is backed up by another quote > from RFC4291: "The details of forming interface identifiers are defined > in the appropriate "IPv6 over <link>" specification" Yes, but nay other link technology (none is defined so far AFAIK) would have to comply with what RFC 4291 says "Modified EUI-64 format-based interface identifiers may have universal scope when derived from a universal token (e.g., IEEE 802 48-bit MAC or IEEE EUI-64 identifiers". The "e.g." in this sentence implies that significance of the u bit isn't limited to EUI-64 derived IIDs. > Even the IEEE definition of EUI64 in > http://standards.ieee.org/develop/regauth/tut/eui64.pdf states > > Quote "When an EUI-64 is used within the context of an IEEE standard, > the standard shall be reviewed by the IEEE RAC for correctness and > clarity. When an EUI-64 is referenced within non-IEEE standards, there > shall not be any reference to IEEE unless approved by the IEEE RAC." > > Was this coupling of standards ever reviewed by the IEEE? This has no implication on universally reserved IID structures of the future, provided they have u=1 and are unambiguously distinguishable from that EUI-64 derived IIDs. > Because it seems to me that the lack of universally clear handling of > the u=1 g=1 case in IETF documents would not fit with the existing IEEE > definition of EUI64, where u=1 g=1 is clearly a globally administered > multicast address, and is not available for any other use. Misunderstanding. U=g=1 does remain AVAILABLE for new IID structures because multicast addresses you refer to aren't concerned with the Modified EUI-64 format. They have 112-bit Group IDs as opposed to 64-bit Interface IDs (refs. https://tools.ietf.org/html/rfc4291#section-2.7) and https://tools.ietf.org/html/rfc4291#section-2.5). > So my conclusion is that any coupling between IEEE and IETF standards > should be weak at most, and also limited to individual links. Limited to links, YES. Weak, NO REASON. Regards, RD -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
