2013-02-06 17:41, "Bless, Roland (TM)" <[email protected]> :
> Hi, > > Am 06.02.2013 14:52, schrieb Rémi Després: >> As already said, the 4rd range only makes a first use of an existing >> RFC4291 provision: "The use of the universal/local bit in the >> Modified EUI-64 format identifier is to allow development of future >> technology that can take advantage of interface identifiers with >> universal scope." > > As it turns out now, this assumption is probably no longer true. This isn't an "assumption", this is just a quote of RFC 4291. >> - Once more: existing implementations have NOTHING to do (as long as >> they don't add 4rd support). Expressed doubts on this should be >> justified by a detailed technical justification. If you have any, >> let's look at it. > > I was talking more about implications on new/forthcoming/updated > implementations. Do they need to keep a list of reserved IIDs > and check against them? No, they don't. > This seems to be a bad idea IMHO. > We have no clear rules for this yet. If it would be the case, yes, it would be a bad idea, but it isn't the case. >> - The reserved range is a tool to AVOID conflicts. It isn't, like >> DAD, a tool to RESOLVE them when they occur. > > That's exactly my point: what should future implementations > do in order to avoid such conflicts? Nothing new needs to be done in any implementation other than that of a 4rd-supporting devices (4rd CEs and BRs). > In case that they are > not using 4rd, MUST they exclude this IID range? Because of RFC 4291 is as it is, softwares that assign IIDs NEVER do it with u=g=1 => they don't need any update to exclude the 4rd range. (That's precisely why the 4rd range has been chosen with u=g=1). Regards, RD > > Regards, > Roland -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
