On Fri, Dec 21, 2012 at 2:57 PM, Rémi Després <despres.r...@laposte.net> wrote: > 2012-12-2110:49, Ole Troan <otr...@employees.org> : > ... >>> (*) >>> 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.
and what is a site? thought we gave up that definition ages ago? >>> 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. again, can you please give us a brief summary instead of just "claiming" it has already been solved? -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
