Francis Dupont wrote:
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).
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
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
