2012-12-2110:49, Ole Troan <[email protected]> : ... >> (*) >> 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?
There is no relation between this subject and whether assigning to 4rd an IID range having u=g=1 is "actually compatible with the IPv6 addressing architecture", which is the question asked to 6man by Suresh. > I don't know what an intra-site IID is. An IID that is used in within a site. > >> 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. Indeed, as you noted in another mail, that's RFC 4291 that says it ;-). > 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. This can be continued offline if you insist, but there has already been discussions in Softwire on this subject, with no issue left. >>> - 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. When supporting RFC 4941 a node forces u = 0. Its implementation obviously doesn't need to be changed because an additional use of u=1 is specified. Ole, your expressing such unchecked objection is a pain. >>> 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. Different view. RD -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
