Hi Margaret, As long as if two networks merge the following is strictly prohibited:
two nodes now appear on the network with: 4ff3::2 4ff3::2 So if two networks heal or merge then DAD must be performed fixed per addr conf as you suggest. That is not what got presented at Yokohama. The other issue I have is an implementation one. If we do this and I am not 100% convinced it is required or what problem we are solving and that would be nice to see. The implementation is that if two nodes have competing implementations. If one node checks the entire address and the other does not then we could end up with in practice in the field with what I want to be prohibited. I also need to think on other architecture ramifications to current implementation like the way we account for duplicate prefixes combined with EUI. thanks /jim > -----Original Message----- > From: Margaret Wasserman [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 09, 2002 9:59 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: DAD vs. DIID > > > > Hi Robert, > > >Maybe I am missing something here, but, if the > >Interface Identifier is not unique anymore on a > >link, what is it then supposed to identify and > >be used for ? > > The suggestion doesn't change the purpose of an IID, just > the scope of its uniqueness. > > In the current (pre-change) addressing architecture, an IID > is unique on the link. So, within the scope of a given link, > the IID can be used to identify a particular interface (and, > by extension, a given node). > > This change would modify the scope of that uniqueness to be > a subnet prefix, not the whole link. So, within a set of > interfaces using a particular subnet prefix, the IID would > identify a particular interface. Most links will have > multiple subnet prefixes in use, because they will have a > link-local prefix and a global prefix. Some links may have > many subnet prefixes in use (link-local, one or more > site-local subnets and one or more global subnets). > > Have you seen the slides that Steve Deering presented on > this subject? If they aren't already up on the IETF > proceedings page, they should be shortly. They give an > example of what this means. > > Although the wording is fairly arcane in order to be > exactly correct, the real change comes down to this: > > OLD: IIDs are required to be unique on a link. > > NEW: Only complete addresses are required to > be unique on a link. > > Relaxing the restriction to the second case makes the use of > privacy addresses easier, it doesn't require any major changes > to implementations (we are already doing Duplicate _Address_ > Detection, not Duplicate IID Detection), and it meets the > requirements to uniquely identify a node for communication. > > A side-effect of this change is that we will need to update > the Address Autoconfiguration spec to require the use of DAD > on all addresses, and not allow the currently documented > optimization to only perform DAD on the link-local address. > > I can only think of two cases where the same IID would get used > for different hosts on the same link: > > - If some hosts on the link do not configure global > addresses, but others do. > > - If there are two (or more) subnets running over the > same link, and not all of the hosts on the > link are members of both (or all) subnets. > > >Also, how would then the Link Local address be formed ? > > Not all IIDs are used to create link-local addresses. An > interface is required to have at least one link-local address, > and the IID used to create that address must be different than > the IIDs used to create link-local addresses on other interfaces > on the same link (as required by the per-subnet uniqueness clause, > and as checked by DAD). But it is not necessary, for example, to > create link-local addresses with the randomly generated IIDs used > to create privacy addresses. > > It is important for folks to understand what we are changing > here, so please let me know if any of the above is confusing > or unclear. > > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
