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

From: "Suresh Krishnan (QB/LMC)" <[email-masked]>
Date: Tue, 22 Jul 2003 11:08:24 -0400

Hi Greg,
	You are right. This seems to be carried over from RFC 2460. For people who have been involved with IPv6 since then this might be natural. As a new implementor this was confusing to me. Because nobody else complained probably there is no need to correct it? It is upto the WG to decide.

Regards
Suresh

-----Original Message-----
From: Greg Daley [mailto:[email-masked]]
Sent: Tuesday, July 22, 2003 3:01 AM
To: Suresh Krishnan (QB/LMC)
Cc: [email-masked]'
Subject: Re: RFC 3513 EUI-48/MAC-48 confusion

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:
> 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?

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.
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Tue, 22 Jul 2003 18:02:03 +0200

In your previous mail you wrote:

   	You are right. This seems to be carried over from RFC
  2460. For people who have been involved with IPv6 since then this
  might be natural. As a new implementor this was confusing to
  me. Because nobody else complained probably there is no need to
  correct it? It is upto the WG to decide.
   
=> this is an old issue. IMHO the best solution is to consider
the MAC-48 -> EUI-48 -> EUI-64 transform in place of the direct
MAC-48 -> EUI-64 transform. BTW the EUI-64 stuff is a big joke:
*no* IEEE layer 2 uses EUI-64s as addresses today (IEEE 1394 aka
I-Link aka FireWire uses 6 bit node addresses).

Regards

[email-masked]

---

From: Greg Daley <[email-masked]>
Date: Wed, 23 Jul 2003 10:04:19 +1000

Hi Francis,

> I-Link aka FireWire uses 6 bit node addresses).

It's an old issue maybe, but has caused
confusion here, and may do so in the future.
This is because the IETF's proposed standard
is incorrect.

If the proposal you mentioned is useful, then
why don't we formalize it in text, or (more
to the point) abandon the example in the
document and refer to the IEEE's authoritative
description of EUI64?

I'm not worried about the chance of address collisions
because of existing implementations really.
It makes sense to update the text when
the document is revisited for the site-local
clean-out.

Greg

---

From: Robert Elz <[email-masked]>
Date: Wed, 23 Jul 2003 19:35:29 +0700

Date:        Tue, 22 Jul 2003 18:02:03 +0200
    From:        Francis Dupont <[email-masked]>
    Message-ID:  <[email-masked]>

  | => this is an old issue.

Yes.

  | IMHO the best solution is to consider the MAC-48 -> EUI-48

Is there such a thing?   I thought that MAC-48 and EUI-48 were
distinct (though very similar looking) number spaces.

  | BTW the EUI-64 stuff is a big joke:
  | *no* IEEE layer 2 uses EUI-64s as addresses today

It certainly is currently.   There isn't likely to be a link layer
that uses EUI-64 until something remarkably new appears (something
that no-one wants to be compatible with ethernet in any way) but
which is designed to be of similar utility to ethernet.   This
combination is perhaps unlikely...

But it does no real harm to allow for EUI-64 - we want IPv6 addressing
to last for MANY years into the future - EUI-64 is certainly a plausible
addressing structure for some future link layer to adopt (given that
it is defined, etc).   If it never happens, big deal (we're not about
to switch IPv6 addresses to be 112 bits, and nor do we need more than
64 bit prefixes (48 bit site identifiers)).

On the original point - the stupid thing is that Deering (I think) had
the transformation defined originally using FFFF (the correct value to
convert MAC-48 to EUI-64), but the WG was then told that was the wrong
value, and FFFE was the one that should be used.   And we believed it...

I'd suggest now just documenting the thing, perhaps reserving FFFE for
EUI-48 to EUI-64 conversion in IPv6 addresses (should this ever be
needed).   IPv6 addresses don't use "true" EUI-64 anyway, they have
the U/L bit inverted.   If it is OK to invert one bit,  it must also
be OK to (sometimes) invert another bit...   It is weird, but it
costs nothing beyond the explanation in the doc.

kre

---

From: Francis Dupont <[email-masked]>
Date: Wed, 23 Jul 2003 16:35:05 +0200

Is there such a thing?

=> not really but the difference between MAC-48 and EUI-48 is
more a problem of interpretation (address != identifier) than
something else.

   I thought that MAC-48 and EUI-48 were
   distinct (though very similar looking) number spaces.
   
=> The IEEE (http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html)
is not cristal clear about this: overlap between spaces is discouraged
but not forbidden. So as the real issue is possible collisions between
EUI-64s from real EUI-48s and EUI-64s from MAC-48s using our bogus
translation rule, IMHO this is not (yet) a real issue. BTW, as they are
defined by the IEEE, we should not get real EUI-48s in an IPv6 context.

=> I agree...

Thanks