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]
--------------------------------------------------------------------

Reply via email to