Margaret,

I think all vendors will provide option to disable DAD and take the
risk.  

The IETF specs are not like laws where they can really be enforced.  If
a customer and set of vendors have a good reason to not use a MUST in a
spec they will for business reasons.  And there is not a thing the IETF
can do about it.

/jim

> -----Original Message-----
> From: Margaret Wasserman [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 04, 2002 2:58 AM
> To: Hesham Soliman (ERA)
> Cc: [EMAIL PROTECTED]
> Subject: Should DAD be optional? [Was
> draft-ietf-ipv6-cellular-host-00.txt -> wg last call?]
> 
> 
> 
> Hi Hesham,
> 
> Thanks for the quick response.
> 
> >=> Then let's begin the discussions. The only reason
> >for standardising the draft in the IPv6 WG was to make
> >sure that we're doing the right thing. Otherwise an 
> >informational RFC wouldn't have to go through the
> >IPv6 WG or could have been replaced by a 3GPP spec.
> >But since the competence is here, it is crucial
> >that we get feedback.
> 
> That sounds good.  Let's begin the discussions...
> 
> I'll send separate threads for each issue.
> 
> >   > 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.
> 
> 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..."
> 
> 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.
> 
> [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.]
> 
> 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]
--------------------------------------------------------------------

Reply via email to