Jeremy, I was not disagreeing (or agreeing) with your assertion. The original e-mail had a question about RFC compliance. If an implementation does not use the EUI-64 (regardless of how you choose to interpret the IEEE EUI-64 specification), it is not compliant with RFC 2464 or 4291; however, operationally, I doubt it matters. Specifically, if DAD is in use (and it is mandated by RFC 4862), then it really does not appear to matter how an implementation forms the Interface ID. As a result, I am not sure that the discussion of how to form an EUI-64 Interface ID is germane to Vijay's original question, which appeared to relate to whether his proposed mechanism for generating an Interface ID would break SLAAC, etc. My take is No for the reasons stated.
Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -----Original Message----- From: Duncan, Richard J. (Jeremy) CONTRACTOR [mailto:[email protected]] Sent: Friday, June 26, 2009 9:22 AM To: Dunn, Jeffrey H.; Bob Hinden Cc: [email protected] Subject: RE: Implementation specific Interface-ID 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: [email protected] [mailto:[email protected]] On Behalf Of Dunn, Jeffrey H. Sent: Thursday, June 25, 2009 9:00 AM To: Bob Hinden; Duncan, Richard J. (Jeremy) CONTRACTOR Cc: [email protected]; [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of Bob Hinden Sent: Thursday, June 25, 2009 7:51 AM To: Duncan, Richard J. (Jeremy) CONTRACTOR Cc: [email protected]; [email protected] 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 [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
