On Wed, Sep 8, 2010 at 11:43 AM, Jon Smirl <[email protected]> wrote: > On Wed, Sep 8, 2010 at 10:40 AM, Mariano Alvira <[email protected]> wrote: >> On Wed, Aug 11, 2010 at 01:35:44AM +0400, Dmitry Eremin-Solenikov wrote: >>> On 8/11/10, Mariano Alvira <[email protected]> wrote: >>> >>> Please refer to the part 'Restricted encapsulated values'. >>> >>> IMO you should have generated EUI-64 directly from OUI/extid >>> EUI-48 -> EUI-64 is really meant for cases where manufacturer >>> provides 48-bit address (like ethernet card), but we need 64-bit >>> one (like in IPv6). >> >> not that I want to revisit this... but I'm trying to do the right >> thing and I came across this: >> >> in RFC4944, section 6: >> >> "The Interface Identifier [RFC4291] for an IEEE 802.15.4 interface may >> be based on the EUI-64 identifier [EUI64] assigned to the IEEE >> 802.15.4 device. In this case, the Interface Identifier is formed >> from the EUI-64 according to the "IPv6 over Ethernet" specification >> [RFC2464]." > > > They are referring to the Interface Identifier, not the 48 to 64 bit > conversion. So starting from the EUI-64 do this.... > > > The Interface Identifier is then formed from the EUI-64 by > complementing the "Universal/Local" (U/L) bit, which is the next-to- > lowest order bit of the first octet of the EUI-64. Complementing > this bit will generally change a 0 value to a 1, since an interface's > built-in address is expected to be from a universally administered > address space and hence have a globally unique value. A universally > administered IEEE 802 address or an EUI-64 is signified by a 0 in the > U/L bit position, while a globally unique IPv6 Interface Identifier > is signified by a 1 in the corresponding position. For further > discussion on this point, see [AARCH]. > > > I did that in the link local address code. Flipping the bit turns it > into a locally administered address - ie link local.
To clarify this, the MAC should have the global form of the EUI64. When generating the link local IP address I convert to the local form in software. > > >> >> And in RFC2464 section 4: >> >> "The OUI of the Ethernet address (the first three octets) becomes the >> company_id of the EUI-64 (the first three octets). The fourth and >> fifth octets of the EUI are set to the fixed value FFFE hexadecimal. >> The last three octets of the Ethernet address become the last three >> octets of the EUI-64." > > This is the description of how to convert a 48b MAC to a 64b one. But > you already have a 64b one so no conversion is needed. Just don't put > FFFE in the middle since that is the special key used in converting > 48/64b. > > >> >> "For example, the Interface Identifier for an Ethernet interface whose >> built-in address is, in hexadecimal, >> >> 34-56-78-9A-BC-DE >> >> would be >> >> 36-56-78-FF-FE-9A-BC-DE." >> >> >> From my understanding of this, the HW address will be the EUI64 and >> and the ipv6 address will have the FFFE in the middle. >> >> So for Redwire, we could have HW: 00-50-C2-A8-Cx-xx-yy-yy >> >> and the "Interface Identifier" would be (I supppose): >> >> 00-50-C2-FF-FE-A8-Cx-xx >> >> but which group of bits to put as "x-xx" doesn't seem properly defined >> (at least for IAB owners). It's also annoying that, I have 28 bits in >> my EUI64, but RFC4944 is saying I can only use 12, even though as you >> state 802.15.4 uses 64-bit addresses and so does ipv6 so why is >> RFC4944 making me go from 64-> 48 -> back to 64? >> >> Does anyone have any thoughts? >> >> -Mar. >> >> > > > > -- > Jon Smirl > [email protected] > -- Jon Smirl [email protected] ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Linux-zigbee-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
