DAD already has rough consensus and running code? What are you talking about?
This is a bit more than a research issue now IPv6 products are shipping. /jim > -----Original Message----- > From: Francis Dupont [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 04, 2002 4:28 AM > To: Margaret Wasserman > Cc: Hesham Soliman (ERA); [EMAIL PROTECTED] > Subject: Re: Should DAD be optional? [Was > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > In your previous mail you wrote: > > > > It is not my impression that the WG has reached > consensus on some > > > of the issues raised in this document, specifically: > > > > > > - Forbidding the use of DAD on some links > > > >=> DAD is not needed if address duplication is not > >possible. Since each terminal gets a unique > >/64 (as per the advice draft), and since all terminals > >are on p2p links, DAD would be a waste of BW. > >But please have a closer look and let us know > >if something was missed. > > Address duplication is possible on point-to-point links, because > one end may choose an address that is already in use by the other > end. I don't think that this is very likely, but it is possible. > > => I disagree for addresses using the explicitely negociated > interface IDs with in the first position the link-local addresses. > > However, making DAD optional (and advising against the use of DAD) > on point-to-point links, is in direct conflict with RFC 2462, > which says: > > "Duplicate Address Detection MUST take place on all unicast > addresses, regardless of whether they are obtained through > stateful, stateless or manual configuration..." > > => the point-to-point link is one case DAD is overkilling. > But as too many persons want to make DAD optional I agree > we have to be carefull. For instance we should ask that > all DAD stuff must get rough consensus in the IPv6 WG. > Another point is who makes the choice to avoid the DAD check: > my opinion is this must be the "link manager" (i.e. the manager > of the network where is the link). > > I don't think that we should publish an informational > document that > advises some implementors to do something that specifically > disagrees with a MUST requirement in a standards-track document. > If the standards-track document is broken, we need to fix it > instead. > > => I agree we have a procedural case at least. > > [Please note that I actually think that we should be able to > disable DAD for some link types. I made a proposal to that effect > several years ago, but my arguments didn't win the day.] > > => so basically we agree! > > Thanks > > [EMAIL PROTECTED] > > PS: DAD is not a toy, at least one time I saw it saved us > from a disaster. > -------------------------------------------------------------------- > 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] --------------------------------------------------------------------
