Hi, Fred, On 04/14/2012 10:08 PM, Fred Baker wrote: > Speaking for myself, I don't understand the fixation on MAC > addresses.
What do you mean, exactly? > 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. I think this wasn't assumed by anyone (i.e. we all agree on this). > 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." This still leads to addresses that allow host tracking. -- PLease see Section 7 of my I-D. > 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. In order to get stable addresses within a subnet, that change across networks, you need a scheme such as the one proposed. So I don't follow how the minor mod that you're referring to would address this. > 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 You not only need the ID to change as you move to a different network, but you also want the ID to be the same when you move back to the same network. So I don't follow why you think the path we're following is not the right path. For instance, my document aims to do exactly what you are describing. > (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. So you'd include requirements, but don't specifiy how to comply with them? -- I don't really follow. And also don't follow why one should start with other I-D, when the current one has been discussed, presented, and reviewed by quite a few relevant people, which agreed with the proposal. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
