Re: why 0xFFFE is used in the modified EUI-64 format

2005-12-14 Thread Daniel Roesen
On Thu, Dec 15, 2005 at 02:36:16AM +0100, Daniel Roesen wrote: > Nevertheless, the significance of bits #57 and #58 are not widely > known to IPv6 operators out there. I cannot count. g-bit is bit #56, not #58. My only excuse for this mail flood is that it's almost 3am local time here. :-Z My apol

Re: why 0xFFFE is used in the modified EUI-64 format

2005-12-14 Thread Daniel Roesen
On Thu, Dec 15, 2005 at 01:40:28AM +0100, Daniel Roesen wrote: > "EUI-64" == "IEEE EUI-64" != "modified EUI-64". > > The modification is exactly the flipped bit. See 2.5.1: Please ignore my comment completely. I was thinking of the u/g bits, which are NOT relevant to the FF-FF and FF-FE thing, un

Re: why 0xFFFE is used in the modified EUI-64 format

2005-12-14 Thread Daniel Roesen
On Thu, Dec 15, 2005 at 01:40:28AM +0100, Daniel Roesen wrote: > 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. :-) s/upper 3 host bits/upper 3 bits 001 through 111 [except multicast .

Re: why 0xFFFE is used in the modified EUI-64 format

2005-12-14 Thread Daniel Roesen
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 fo

Re: why 0xFFFE is used in the modified EUI-64 format

2005-12-14 Thread Suresh Krishnan
Hi Jinmei, I was confused by the same inconsistency couple of years ago and a thread resulting from my question failed to clarify the choice. I guess it is something we have to live with. You can look at this thread. http://www.atm.tut.fi/list-archive/ipng/msg10039.html Cheers Suresh JINMEI Ta