>> Also, is there any reason not to choose (for example) >> FDFE:0000:0000:0000-FDFE:FFFF:FFFF:FFFF >> which is near the existing anycast range ? > > No objection that I can see. > Support for including this in the 6man answer.
I think this is better than making any assumption abut the u/g flags. even so I do feel uneasy about this proposal. - principally I think we should design protocols that do not depend on well known addresses or ports. - I believe the IPv6 interface identifier should be of length 128-n, and not carry any structure. at a stretch I can accept reserved identifiers for anycast addresses. - even for reserved interface identifiers, an implementation must handle conflicts. anycast does that implicitly. I'm not sure how 4rd does that. wouldn't putting two 4rd CEs on the same link, break? - the size of the reservation. do we want to reserve 2^48 addresses out of every interface-id, and update every implementation? for an experimental mechanism? I think that a mechanism that requires a large swath of interface-id space, and does not handle collisions, should use a separate prefix on a virtual interface. cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
