2012-12-12 12:45, Brian E Carpenter <[email protected]> : > I think the only way to make progress on this question is to > discuss two points in a much more general way: > > 1. Does the current mapping of the "u" bit in the modified EUI format have > any value? > > 2. Does the current mapping of the "g" bit in the modified EUI format have > any value? > > If the answer to these questions is "no" we could start by saying that they > are *not* mapped from an IEEE EUI into a modified EUI, and then consider > how to use them in future.
Agreed that this issue introduces an opportunity to clarify the general picture. Not sure however that the two proposed questions are clear enough because today: - some IIDs have u = 0, and some have u = 1, - some IIDs have g = 0, and some have g = 1. The only combination that isn't used is u=g=1. A point that is relevant, I think, is that local-scope IIDs, having u = 0, have any values in the 63 other bits. Despite the name "modified EUI-64", these values aren't constrained in any way by the IEEE EUI-64 format. The natural conclusion I see is that IETF is free to define any new IID formats that have u=g=1. IEEE isn't concerned more than it was when IETF specified the privacy option with u = 0. Would this be acceptable? Regards, RD > > Regards > Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
