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
--------------------------------------------------------------------

Reply via email to