Remi, >>>> 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. > > Wow, what a list ! > Let me try to make you comfortable. > >> - principally I think we should design protocols that do not depend on well >> known addresses or ports. > > This is a debatable viewpoint but, more important, it isn't a problem for > 4rd: neither any WKA nor any WKP is needed. > >> - 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. > > No change to RFC 4291 is proposed in this respect. > > However, 4rd addresses, which are concerned with the requirement that "All > Global Unicast addresses other than those that start with binary 000 have a > 64-bit interface ID field", must have 64-bit IIDs. > > >> - 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? > > (*) > 4rd implementors are free to add code to reject any intra-site IID that (by > mistake) would be universal-scope, and in the 4rd-assigned IID range.
but the current specification does not handle conflicts? I don't know what an intra-site IID is. > Whether including this extra complexity would be valuable enough is > debatable, not forgetting that: > - 4rd is experimental > - RFC 4862 says "IPv6 nodes are not required to validate that interface > identifiers created with modified EUI-64 tokens with the "u" bit set to > universal are unique". (There is no guarantee that DAD will prevent all > misuses of universal-scope IIDs.) that's not quite what 4862 says. if the purpose of the reserved block is to avoid conflict with existing nodes on the link, then that idea trivially breaks when you put two 4rd CEs on the same link. >> - 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? > > There must be a misunderstanding somewhere: no existing implementation needs > to be modified (unless 4rd support is added to it). if you reserve a block out of the interface-id space, then all implementations that create interface identifers must be aware of it, to avoid creating conflicts. I don't understand why this additional reservations wouldn't require all nodes that implement RFC4941 to have to be updated. >> 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. > > Regarding collisions, see (*) above. > What you view as a large swath is in fact only 1/2^16 of the total IID space, > nothing to feel uncomfortable about. quite. cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
