Subject: RFC 3513 EUI-48/MAC-48 confusion

From: "Suresh Krishnan (QB/LMC)" <[email-masked]>
Date: Mon, 21 Jul 2003 17:15:41 -0400

Hi Folks,
  Maybe this has been raised before, but I have not found any answers. Appendix A of RFC 3513 has the following text

<<<< FROM RFC3513
Links or Nodes with IEEE 802 48 bit MAC's

   [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).  For example, the 48
   bit IEEE MAC with global scope
<<<< FROM RFC3513

The referred document [EUI64] talks about a different method of creating EU-I64s from MAC-48s. The procedure followed in the RFC seems to be the one recommended for EUI-48s. Is this the intended behaviour?

Thanks
Suresh
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Chirayu Patel" <[email-masked]>
Date: Tue, 22 Jul 2003 08:01:49 +0530

Hi,

Can you quote the text from
(http://standards.ieee.org/regauth/oui/tutorials/EUI64.html) which you think
is contradicting Appendix A of RFC3513.

As per my understanding, the two match. Section "Encapsulated MAC-48 values"
in the tutorial says the same thing as Appendix A, which is to place the
bytes 0xff, and 0xfe between the OUI id (company id of 3 bytes), and
extension identifier (vendor supplied id of 3 byes)

Regards
CP

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of Suresh Krishnan (QB/LMC)
> Sent: Tuesday, July 22, 2003 2:46 AM
> To: [email-masked]'
> Subject: RFC 3513 EUI-48/MAC-48 confusion
> 
> Hi Folks,
>   Maybe this has been raised before, but I have not found any answers.
> Appendix A of RFC 3513 has the following text
> 
> <<<< FROM RFC3513
> The referred document [EUI64] talks about a different method of creating
> EU-I64s from MAC-48s. The procedure followed in the RFC seems to be the
> one recommended for EUI-48s. Is this the intended behaviour?
> 
> Thanks
> Suresh

---

From: "Chirayu Patel" <[email-masked]>
Date: Tue, 22 Jul 2003 08:05:56 +0530

Hi,

As per my understanding, the two match. Section "Encapsulated MAC-48 values"
in the tutorial says the same thing as Appendix A, which is to place the
bytes 0xff, and 0xfe between the OUI id (company id of 3 bytes), and
extension identifier (vendor supplied id of 3 byes). The same procedure
applies to EUI-48 ids.

Regards
CP

---

From: "Chirayu Patel" <[email-masked]>
Date: Tue, 22 Jul 2003 08:27:31 +0530

Digging some more, I realized that there is indeed an inconsistency in the
tutorial. 

The text says - "A unique EUI-64 value is generated by concatenating the
OUI, an FFFE valued label, and the extension identifier values. The (MAC-48
like) transmission-ordered binary representation for this encapsulated
MAC-48 identifier is listed below:". The examples show FFFF. I think the
general protocol is that we should go with the text.

I tried looking in the archives but could not find any emails clarifying
this inconsistency.....

Regards
CP

> [email-masked]] On Behalf Of Chirayu Patel
> Sent: Tuesday, July 22, 2003 8:06 AM
> To: 'Suresh Krishnan (QB/LMC)'
> Cc: [email-masked]
> Subject: RE: RFC 3513 EUI-48/MAC-48 confusion
> 
> Hi,
>

---

From: Greg Daley <[email-masked]>
Date: Tue, 22 Jul 2003 17:01:10 +1000

Hi Suresh,

I think that you are correct that the document
which is referred to indicates the addition
of FFFF for MAC-48 and FFFE for EUI-48.

Maybe this is because the terminology has been
confused previously.

In this instance, though we're definitely
discussing MAC-48's though (as indicated
by the section title).

Suresh Krishnan (QB/LMC) wrote:
 > EU-I64s from MAC-48s.
> The procedure followed in the RFC seems to be the one recommended for
 > EUI-48s. Is this the intended behaviour?

I think that the disinction between EUI-48 and MAC-48
in IETF standards documentation has been mistakenly
blurred.

In this case, EUI-48 and MAC-48 should be considered
distinct numeric spaces, but aren't.  The pre-existence
of this text in RFC2460 means that existing implementations
of IPv6 will utilize this incorrect mechanism.

So we may have increased the chance that EUI-64 IPv6
addresses will have collisions (up to doubled! :)
because of the mapping of these spaces onto the same
part of the EUI-64 space in RFC2460 and RFC3513.

I'm not sure if we can really fix this issue, but we may be
able to change the text in the document so that it is correct
(refers to EUI-48 only rather than MAC, or maybe says MAC-48
with FFFF).

Is it worth doing for correctness?

Greg.