2012-12-20 13:46, Ole Troan <otr...@employees.org>: >>> 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. 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.) > - 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). > 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. Hoping to have addressed all your fears, Cheers, RD > > cheers, > Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
