Speaking for myself, I don't understand the fixation on MAC addresses. Yes, Ethernet and other IEEE standards are widely used. They are not used on serial links (we seem to mostly use /127 prefixes for that), they are not used on the air side of 3G etc, and so on. And as a matter of fact, for all the discussion of Modified EUI-64 aaddresses in RFC 4291, a host or router sending a packet to another host or router that is directly connected at L3 doesn't extract his peer's MAC address from his IPv6 EID. The point of using a MAC address to generate an EID was to make it likely that the EID was unique within the subnet, not to derive it back again. Once it's an EID, it doesn't matter how it was derived. So from my perspective, the entirety of Appendix A and section 2.5.1 could be replaced with "The EID is intended to be a 64 bit number unique within the subnet. One way to generate such a number is from another number such as is specified by EUI-64, EUI-48, E.164, or E.212, an IPv 4 address, or a serial number specific to the hardware in question."
The point of this document is that *another* way to generate it is using a random number generator (privacy addresses), but in such a case there may be certain stability requirements for operational reasons. May I suggest that the right way to address this is to use much of fernando's technical commentary to substantiate the stability requirements and the need to change it when the prefix is changed (for reasons including a change of LAN, but also including renumbering events) and write a short document updating RFC 4291 to remove the fixation on one of many possible EID types. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
