Hi Chirayu,
There is no inconsistency in the tutorial. It mandates use of FFFE for EUI-48
identifiers (not MAC-48). The 802 addresses are MAC-48s. The inconsistency is in the
RFC as it uses the EUI-48 method on MAC-48s.
Regards
Suresh
-----Original Message-----
From: Chirayu Patel [mailto:[EMAIL PROTECTED]
Sent: Monday, July 21, 2003 10:58 PM
To: Suresh Krishnan (QB/LMC)
Cc: [EMAIL PROTECTED]
Subject: RE: RFC 3513 EUI-48/MAC-48 confusion
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
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:owner-
> [EMAIL PROTECTED] On Behalf Of Chirayu Patel
> Sent: Tuesday, July 22, 2003 8:06 AM
> To: 'Suresh Krishnan (QB/LMC)'
> Cc: [EMAIL PROTECTED]
> Subject: RE: RFC 3513 EUI-48/MAC-48 confusion
>
> 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). The same procedure
> applies to EUI-48 ids.
>
> Regards
> CP
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:owner-
> > [EMAIL PROTECTED] On Behalf Of Suresh Krishnan (QB/LMC)
> > Sent: Tuesday, July 22, 2003 2:46 AM
> > To: '[EMAIL PROTECTED]'
> > 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
> > 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 PROTECTED]
> > --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> 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 PROTECTED]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
