Subject: RE: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?]

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 11:48:53 -0500

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-masked]]
> Sent: Monday, March 04, 2002 2:58 AM
> To: Hesham Soliman (ERA)
> Cc: [email-masked]
> 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-masked]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Wed, 06 Mar 2002 14:04:19 -0500

> The IETF specs are not like laws where they can really be enforced. 

I think most of us understand this already.  However, the IETF specs
do establish widely-held assumptions for what is needed to allow
products to interoperate.  Vendors who ship products that violate those
specs are risking that their products will not harm interoperability.
Customers can hold those vendors liable for violating the specifications,
especially if they don't bother to document the violations and/or problems 
that result.  Admittedly this doesn't happen as often as it should.

Within IETF, the best we can do is to produce clear guidelines for what
is expected.  The harm that will result if the expectations are violated 
is not always possible to document in advance.  Just look at the level
of denial that's still occuring about the harm that NATs cause.

Keith