Hi Jeffrey, Reply inline.
> RFC 4291 states in section 5.1: > > "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." => I am not sure this is not the only way I can form a Modified EUI-64 Interface-ID. Agreed that "Links or Nodes with IEEE 802 48-bit MACs" generally use this method. But I don't think its a MUST. RFC 4291 mentions 2 other types of Modified EUI-64 Interface Identifiers, "Links with Other Kinds of Identifiers" and "Links without Identifiers" under "Appendix A: Creating Modified EUI-64 Format Interface Identifiers". As I am generating only a "Locally unique Interface-ID", can't I claim to fall under "Links without Identifiers"? I would think I'd be complaint to RFC 4291. Further, since you appear to be using 64-bit Interface ID's , all the implementations I have come across should interoperate with your methodology. => I forgot to mention that I also ensure that the octets "x,y,z,w" I use is NOT the bit-pattern "FFFE", thereby ensuring that it does not clash with any autoconf addresses generated in the usual way. RFC 2464 does'nt say its a "MUST" to generate Modified EUI-64 Interface-ID from IEEE 802 48-bit MAC in order to be complaint. So, why do you think I would'nt conform to RFC 2464? Thanks & Regards Vijay On Thu, Jun 25, 2009 at 6:29 PM, Dunn, Jeffrey H.<jd...@mitre.org> wrote: > Vijay et al., > > RFC 4291 states in section 5.1: > > "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." > > Further, RFC 4291 is referenced in RFC 2464 (actually, it is the previous > version) as providing further guidance on the formation of Interface ID's. > > As a result, it appears to me that your methodology is not compliant with > either RFC 2464 or 4291. That said, DAD should take care of any operational > problems associated with not using the modified EUI-64. Further, since you > appear to be using 64-bit Interface ID's , all the implementations I have > come across should interoperate with your methodology. > > Best Regards, > > Jeffrey Dunn > Info Systems Eng., Lead > MITRE Corporation. > (301) 448-6965 (mobile) > > > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Bob > Hinden > Sent: Thursday, June 25, 2009 7:51 AM > To: Duncan, Richard J. (Jeremy) CONTRACTOR > Cc: nav...@nav6tf.org; ipv6@ietf.org > Subject: Re: Implementation specific Interface-ID > > Duncan, > >> Vijay- >> >> The only thing I could find is that it's just standard practice to >> use FF >> FE.. For example, if you use privacy extensions then there is no FF FE >> because its address is hashed right? > > No, there is no FF FE because the IIDs created by RFC4941 have local > significance. From section 3.2.1: > > 3. Take the leftmost 64-bits of the MD5 digest and set bit 6 (the > leftmost bit is numbered 0) to zero. This creates an interface > identifier with the universal/local bit indicating local significance > only. > > IIDs with local significance only need to be unique on the link. > Suggest reading the IID relateds sections and appendix in RFC4291. > > >> I think it's just a 16 bit filler for a >> MAC 48.. See below from the IEEE: >> >> http://standards.ieee.org/regauth/oui/tutorials/EUI64.html > > > The FFEE is used to extend an EUI-48 to an EUI-64. It is defined in > the Section titled "Encapsulated EUI-48 values". Namely, "A unique > EUI-64 value is generated by concatenating the company_id, an FFFE > valued label, and the extension identifier values". > > >> Even RFC 4291 didn't really go into much detail either.. >> http://www.ietf.org/rfc/rfc4291.txt > > RFC4291 references the above mentioned EUI64.html document. > > Bob > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
