Margaret Wasserman wrote: > > > >While it might sound theoretically nice to be able to reuse > an IID on > >multiple nodes on a single subnet, the operational reality > is that it > >will be confusing and never used in practice. > > IID uniqueness on a link is an artificial restriction: We > don't check for it with DAD, and not other part of the IPv6 > architecture depends on it. Leaving it in will complicate > privacy addresses and some other situations, and taking it > out does not actually require operators to number their > networks in a confusing fashion. > > In practice, permanant addresses probably won't have > overlapping IIDs. Autoconfigured addresses will never have > overlapping IIDs because there will always be a corresponding > link-local address that is check for uniqueness with DAD. > And, I expect you are correct that operators will not > manually configure multiple nodes on a link to use the same IID. > > However, there are two cases where overlapping IIDs may occur: > > - Randomly-generated IIDs used for privacy addresses. > To prevent the possibility of overlapping IIDs in > this case, we'd have to generate a link-local > address and perform DAD on it (or some equivalent), > in addition to performing DAD on the privacy address.
And the problem with running an additional DAD is??? LL with privacy IIDs make no sense, so why wouldn't the node just configure all the available prefixes and defend them directly? Even without the LL-DAD, the only case where a collision would not be detected is when a subnet has multiple prefixes, but nodes are not configured to use all of them. In real networks, the likelyhood that some nodes on a wire would use one prefix while others use a different one is so close to 0 that it shouldn't be special cased. > > - Two separate subnets that are merged onto a single > physical network (due to topology changes, etc.). > If these were manually configured networks, its > likely that both sets of IIDs will include the > same low numbers. However, the original global > and site-local addresses could still be distinguished > by their different subnet IDs, so why require the > IIDs to change? Because it will happen anyway to avoid the operator confusion of multiple nodes with the same IID. I can appreciate the desire to perpetuate legacy procedures and allow the concept of 2 logical subnets on the same wire, but with the IPv6 concept of multiple prefixes per subnet, that becomes a real mess. Since these are theory, what happens in the merge example if both sites were using autoconf based on configured macs of 1,2,3...? In the real world when 2 subnets are merged, one or both of them require reunmbering, so why should we change the address architecture to allow a case that might someday make creating a confusing mess easy? > > I don't see any reason why we should keep an artificial > restriction in the addressing architecture that would > complicate either of these cases. Because they are theoretical scenarios, not something that a network operator would expect to have work. > > Margaret > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
