Re: Implementation specific Interface-ID

[Vijayrajan ranganathan <vijayrn at gmail.com>]

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.<jdunn at 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-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On Behalf Of Bob Hinden
> Sent: Thursday, June 25, 2009 7:51 AM
> To: Duncan, Richard J. (Jeremy) CONTRACTOR
> Cc: nav6tf at nav6tf.org; ipv6 at 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 at ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 at ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>