Subject: EUI-64 based interface identifiers

From: "Andreas Herrmann" <[email-masked]>
Date: Thu, 8 Aug 2002 10:48:26 +0200

Hi,

I have 2 questions regarding EUI-64 based interface
identifiers.

On Linux for zSeries we face the scenario that various Linuxes
on one machine might share the same network (Fast/Gigabit
Ethernet) card. Of course this card has just one MAC address.
To avoid detection of duplicate addresses during stateless
autoconfiguration we are replacing the part 0xFFFE of the link
local address by a 16-bit value. This value is unique among all
Linuxes sharing the same network card.

A MAC of 00:04:AC:7C:BC:48 for a shared network card would result
in the following link local addresses for the Linuxes sharing this
card:

Linux 1: fe80::4:ac00:17c:bc48
Linux 2: fe80::4:ac00:27c:bc48
Linux 3: fe80::4:ac00:37c:bc48
...

This procedure does not correspond to what is written in RFC 2373
"Appendix A: Creating EUI-64 based Interface Identifiers" and in
"http://standards.ieee.org/regauth/oui/tutorials/EUI64.html".
The algorithm described there would result in a link local address
of fe80::204:acff:fe7c:bc48 for all Linuxes sharing the same card.

But we are not inverting the "u" bit in the resulting interface
identifiers. Hence the resulting 64-bit interface identifiers have
local scope.

According to a short discussion about a similar topic that happened
on this mailing list quite a long time ago (I found it in the mail
archive, file ipng.200002):

"=> you can do what you want when the global bit is reset/reversed."

Thus I assume the above procedure -- replacing 0xFFFE by a unique
identifier and not inverting the "u" bit -- does not violate
any RFCs.
Am I right in this assumption?

Another question is:
Do you know of any applications that rely on the part
"FFFE" of interface identifiers? E.g. network sniffers might use
the value to identify interface identifiers.

Regards,

Andreas Herrmann

--
Linux for eServer Development
Tel :  +49-7031-16-4640
Notes mail :  Andreas Herrmann/GERMANY/IBM@IBMDE
email :  [email-masked]

--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Sun, 11 Aug 2002 13:24:08 +0700

Date:        Thu, 8 Aug 2002 10:48:26 +0200
    From:        "Andreas Herrmann" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I have 2 questions regarding EUI-64 based interface
  | identifiers.

It doesn't appear as if anyone has attempted to answer your question yet.

  | To avoid detection of duplicate addresses during stateless
  | autoconfiguration we are replacing the part 0xFFFE of the link
  | local address by a 16-bit value. This value is unique among all
  | Linuxes sharing the same network card.

Sounds like an interesting technique.

  | This procedure does not correspond to what is written in RFC 2373
  | "Appendix A: Creating EUI-64 based Interface Identifiers" and in
  | "http://standards.ieee.org/regauth/oui/tutorials/EUI64.html".

No.  It certainly isn't that.

  | But we are not inverting the "u" bit in the resulting interface
  | identifiers. Hence the resulting 64-bit interface identifiers have
  | local scope.

If you've been following the list discussion recently, you'll see that
"local scope" is a meaningless concept anyway (or rather, everything
really only has local scope, global scope is meaningless.)   Of course
you might also understand that there are apparently some others who
disagree with this viewpoint, but we don't know who or why.

What is clear is that doing that essentially means you're using addresses
from the "other configuration" area, and as what you're doing is "other
configuration" (it isn't autoconfig as defined), that looks to be the right
thing to do to me.

Just expect a higher probability of a clash with some other manually
configured address than you'd get with a normal autoconfig mechanism, and
be able to cope with that (the probability is still likely to be quite
low).

  | Thus I assume the above procedure -- replacing 0xFFFE by a unique
  | identifier and not inverting the "u" bit -- does not violate
  | any RFCs.
  | Am I right in this assumption?

I believe so, yes.   Not that it matters anyway, provided the user of
the system is happy to have addresses used this way - it is address space
assigned to that user (link locals just being the first step I assume)
that is being consumed here.

That is, as long as the user can override what you're doing by default,
and assign addresses more in line with their address plan, this all looks
just fine.

  | Another question is:
  | Do you know of any applications that rely on the part
  | "FFFE" of interface identifiers? E.g. network sniffers might use
  | the value to identify interface identifiers.

Unless someone is able to say "yes" (which I truly hope no-one is going to
do), this is a very hard question to answer meaningfully.

I know of no-one stupid enough to do anything so absurd, but that doesn't
mean that there isn't someone out there acting irrationally.

But don't worry about it - if there's anyone doing that kind of weird
thing, then they're also going to fail on 3041 addresses, and whenever
people just configure <prefix>::1 <prefix>::2 for their systems.

kre