Date: Thu, 8 Aug 2002 10:48:26 +0200
From: "Andreas Herrmann" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| 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
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
