On Sat, Dec 10, 2005 at 02:53:07AM +0900, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote: > According to draft-ietf-ipv6-addr-arch-v4-04.txt (or already-published > RFCs), we insert 0xFFFE in the middle of the interface identifier in > order to convert an 48-bit MAC address to the modified EUI-64 format: > > [EUI64] defines a method to create a IEEE EUI-64 identifier from an > IEEE 48bit MAC identifier. This is to insert two octets, with > hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC > (between the company_id and vendor supplied id). > (in APPENDIX A) > > However, according to [EUI64], we use 0xFFFF (not 0xFFFE) "to create > an EUI-64 identifier from a 48bit MAC identifier" for network devices > (i.e., MAC-48):
"EUI-64" == "IEEE EUI-64" != "modified EUI-64". The modification is exactly the flipped bit. See 2.5.1: <cite> Modified EUI-64 format interface identifiers are formed by inverting the "u" bit (universal/local bit in IEEE EUI-64 terminology) when forming the interface identifier from IEEE EUI-64 identifiers. In the resulting Modified EUI-64 format the "u" bit is set to one (1) to indicate universal scope, and it is set to zero (0) to indicate local scope. The first three octets in binary of an IEEE EUI-64 identifier are as follows: </cite> and the rationale is right below that: <cite> The motivation for inverting the "u" bit when forming an interface identifier is to make it easy for system administrators to hand configure non-global identifiers when hardware tokens are not available. This is expected to be case for serial links, tunnel end- points, etc. The alternative would have been for these to be of the form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 0:0:0:1, 0:0:0:2, etc. </cite> I wonder how well-known the special meaning of the upper 3 bits are to folks who work creativly with the 64 bit host ID space... and the consequences of having them != 000 are. :-) An IPv6 address (not derrived from a globally unique ID like ethernet MAC) with the the upper 3 host bits != 000 and u or g bit set to 1 would be wrong. :-) > I googled and found a web page saying this is "an error": > > Confusingly IPv6 -- one of the most prominent standards that uses > EUI-64 -- applies these rules inconsistenly. Due to an error in the > appendix to the specification of IPv6 addressing, it is currently > standard practice in IPv6 to extend MAC-48 addresses (such as IEEE 802 > MAC address) to EUI-64 using 'FF-FE' rather than 'FF-FF'; it remains > to be seen how this inconsistency will be resolved in the future. > (http://www.kingj.com/articles/MAC_address) > > Is this true, or was there any particular reason for the "confusing" > choice? The only confusion exists in the head of the author of above article. Best regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
