Jeff- Yes, but nothing in the IEEE spec states anything that using the FF and FE bits to supplant a MAC 48 is an absolute requirement for the Modified EUI-64.. If so, please show me, I didn't find anything.
010100110110010101101101011100000110010101110010001000000100011001101001 Jeremy Duncan DTRA (BE-BIC) INFOSEC 3, IPv6 Architect Command Information Office: (703) 767-6167 Cell: (703) 598-1193 -----Original Message----- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Dunn, Jeffrey H. Sent: Thursday, June 25, 2009 9:00 AM To: Bob Hinden; Duncan, Richard J. (Jeremy) CONTRACTOR Cc: nav...@nav6tf.org; ipv6@ietf.org Subject: RE: Implementation specific Interface-ID 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 --------------------------------------------------------------------
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
