Hi Christian, Christian Huitema wrote:
As for anycast and multicast, these addresses supposedly set the "group" bit in the identifiers -- and if they don't they really should, since the L2 transmission is multicast. Setting the G bit differentiates these addresses from RFC3041 addresses.
Agree. How do we go about doing this? erratum for the RFCs in question? bis versions of the RFCs? How about backward compatibility?
I don't think that we have a real problem, and I believe that an additional registry would do more harm than good. It would create an avenue for groups to reserve more identifiers, in the naïve belief that implementations would magically be updated to avoid these numbers. And it would create an extra burden for implementers. Groups that want to reserve identifiers should really use the IEEE 802 processes.
I think there is a real problem. The problem being documents "reserving " interface IDs for special use without actually taking them out of circulation. I agree in principle with you that this is a bad idea. If you look at the IANA considerations of my draft you would see the following text.
It is possible that implementations might predate a specific assignment from this registry and hence not be cognizant of the reserved nature of the interface identifier. Hence. future assignments from this registry are discouraged but in exceptional circumstances are to be made through Expert Review [IANABIS]. Thanks Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------