etation in the past, and so be it.
Bert
> -Original Message-
> From: Bob Hinden [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 20, 2006 5:24 PM
> To: JINMEI Tatuya / 神明達哉; IPv6 WG
> Subject: Re: why 0xFFFE is used in the modified EUI-64 format
>
> One more thi
One more thing,
On Jan 20, 2006, at 12:10 PM, Bob Hinden wrote:
They both use the same 24-bit OUI values. It looks to me like IEEE
decided to deprecate the name MAC-48. Why IEEE choose to have two
different ways to create EUI-64 from these 48-bit identifiers is a
mystery to me. As
Before submitting the new text, I went back and tried to find out
what the difference is between an MAC-48 and an EUI-48. In the
document:
http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html
I found the following:
"The (obsolete label) MAC-48 is a concatenation of a 24-bit OU
Hi,
It's only a note at the end of an appendix, but I wouldn't object to
removing the last sentence if others are troubled by it. The intent
was to provide some advice to someone writing an IPv6 over
specification.
I concur that the last sentence should be removed. It doesn't help
to clari
>>> that uses IEEE EUI-48 and MAC-48 identifiers on the same link,
>>> the
>>> 0xFF and 0xFF values could be used to convert the EUI-48
>>> identifiers
>>> for use as IPv6 interface identifiers to avoid any potential for
>>> duplicate interface identifiers.
>>
>> I said 'personall
Jinmei,
On Jan 18, 2006, at 8:40 PM, JINMEI Tatuya / 神明達哉 wrote:
On Wed, 18 Jan 2006 09:54:51 -0800,
Bob Hinden <[EMAIL PROTECTED]> said:
Here is the text I propose to send to the RFC-Editor to resolve the
issue. Take a look and let me know it is is OK.
I personally support this text with
> On Wed, 18 Jan 2006 09:54:51 -0800,
> Bob Hinden <[EMAIL PROTECTED]> said:
> Here is the text I propose to send to the RFC-Editor to resolve the
> issue. Take a look and let me know it is is OK.
I personally support this text with one very minor nit:
> Add:
> Add to the end of the
Hi,
Here is the text I propose to send to the RFC-Editor to resolve the
issue. Take a look and let me know it is is OK.
Thanks,
Bob
Appendix A: Creating Modified EUI-64 Format Interface Identifiers
.
Links or Nodes with IEEE 802 48-bit MACs
[EUI64] defines a method to cr
On Tue, Jan 10, 2006 at 04:47:57PM +0900, JINMEI Tatuya / [EMAIL
PROTECTED]@C#:H wrote:
> As I proposed in a follow-up message on this thread
> (http://www1.ietf.org/mail-archive/web/ipv6/current/msg06052.html),
> I'd add a note that just clarifies the mismatch. I've attached a
> proposal of cha
> On Mon, 9 Jan 2006 09:51:48 -0800,
> Bob Hinden <[EMAIL PROTECTED]> said:
> Sorry for not responding sooner.
No problem, thanks for the response.
> I suspect that at the time we thought that an EUI-48 was equivalent
> to MAC-48. Actually until you sent your email I wasn't aware of
Jinmei,
Sorry for not responding sooner.
On Dec 9, 2005, at 9:53 AM, ext JINMEI Tatuya / 神明達哉 wrote:
I believe this was discussed and clarified before, but I could not
find any pointer, so let me ask here...
It's regarding the "magic number" of 0xFFFE used in the modified
EUI-64 format for th
> On Wed, 14 Dec 2005 18:49:00 -0500,
> Suresh Krishnan <[EMAIL PROTECTED]> said:
> 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 t
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
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
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
.
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
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
I believe this was discussed and clarified before, but I could not
find any pointer, so let me ask here...
It's regarding the "magic number" of 0xFFFE used in the modified
EUI-64 format for the interface identifier of an IPv6 address.
According to draft-ietf-ipv6-addr-arch-v4-04.txt (or already-p
18 matches
Mail list logo
