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

From: [email-masked]
Date: Mon, 4 Mar 2002 17:31:19 -0800

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

>Yes.

>RFC-2462, "5.1.  Node Configuration Variables":

>  DupAddrDetectTransmits = 0

> => DAD is disabled on link

>So, no DAD is "conformant" too.

This is actually what PPPv6 (RFC2472)suggests:
"As long as the Interface Identifier is negotiated in the IPV6CP phase
   of the PPP connection setup, it is redundant to perform duplicate
   address detection as a part of the IPv6 Stateless Autoconfiguration
   protocol [3].  Therefore it is recommended that for PPP links with
   the IPV6CP Interface-Identifier option enabled the default value of
   the DupAddrDetectTransmits autoconfiguration variable [3] be zero."

Cheers,

Jonne.

--------
Jonne Soininen
Nokia

Tel. +1 650 864 6794
Cellular: +1 650 714 7733
Email: [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: [email-masked]
Date: Wed, 6 Mar 2002 18:54:26 +0200

Hi Jim,

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

Actually, I think what we (the IETF) should do about it is create
specifications which explain what the reason for the specification
is used for, and under what circumstances optimizations may be useful.
This is actually what one of intentions has been for the Cellular Hosts
document.  

In discussing RFCs with non-IETF folks, some of the requirements
in RFCs can seem to be rather arbitrary.

thanks,
John

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 12:02:16 -0500

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-masked]]
> Sent: Monday, March 04, 2002 4:28 AM
> To: Margaret Wasserman
> Cc: Hesham Soliman (ERA); [email-masked]
> 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.
> 
> => so basically we agree!
> 
> Thanks
> 
> [email-masked]
> 
> PS: DAD is not a toy, at least one time I saw it saved us 
> from a disaster.

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 12:09:01 -0500

Pekka,

I object strongly to your assumption we should change RFC 2462.  You
have presented no operational problem or spec or protocol problem.

If you don't think its "useful" thats fine, don't use it.

/jim

> Sent: Monday, March 04, 2002 5:00 AM
> To: Pekka Savola
> Cc: Margaret Wasserman; Hesham Soliman (ERA); [email-masked]
>    I think DAD should be disableable for default for:
>     - addresses generated randomly
> 
> => I *strongly* disagree: even if the probability is small it 
> is not zero.
> 
>     - addresses that are generated from e.g. EUI64 (this 
> might be more prone 
>    to errors, e.g. manufacturing or "stupid" multi-port NIC's 
> where every 
>    port has the same MAC address)
>    
> => I agree: if two boxes have the same hardware number the address
> collision is no more than a detail.
> 
>    Most definitely not:
>     - manually configured addresses
>    
> => agree
> 
>    Because DAD is not a perfect (or even nearly so) solution anyway.
>    
> => DAD is not perfect but only the network manager should take the
> decision to forget DAD in such or such situations. Of course this
> implies the "DAD avoidance" is negociated by the link-layer before
> (so PPP again is a good candidate for optional DAD).
> 
> Regards
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 12:27:44 -0500

James,

I do not think we need to change 2462.  Vendors just provide an option to disable.
Erik's comments on why we did it still apply.  We as protocol designers must require DAD.

/jim

> From: James Kempf [mailto:[email-masked]]
> Sent: Monday, March 04, 2002 12:55 PM
> To: Hesham Soliman (ERA); Margaret Wasserman
> Cc: [email-masked]
> Margaret,
> > I don't think that we should publish an informational document that 
> DAD has a substantial performance impact on handover if the
> Mobile IPv6 care of address is changed. If the address provision
> scheme is such that duplicate addresses are not possible, then
> I believe it should be possible to disable it.
> 
> I agree that the change must be made in the standards-track document.
> Perhaps we could quickly get a short document that describes when 
> DAD can be disabled, so that the issue can be resolved as quickly
> as possible. In the Mobile IPv6 specification, DAD is only a MAY.
> 
>             jak
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 12:01:00 -0500

Pekka,

DAD works and should be mandated in our specs and is.  Its done.

But your free to ship products however you choose.

/jim

> From: Pekka Savola [mailto:[email-masked]]
> Sent: Monday, March 04, 2002 3:46 AM
> To: Margaret Wasserman
> On Mon, 4 Mar 2002, Margaret Wasserman wrote:
>  - addresses that are generated from e.g. EUI64 (this might 
> be more prone 
> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 13:22:44 -0500

John,

For years I used to fight that all specs in the IETF should have rationale appendices as in the IEEE.  But no one wants to do the work.

Your being overly optimistic if you believe what you ask is achievable. 

I don't think the wordage for actual protocol operation is arbitrary for the technologies I have worked on in the IETF for 9 years.  But I do think the policy is and often who yells the loudest or a default that is less than optimal and no one implements it the same for policy then.  That is the part that is arbitrary I say as IMO (IMO not IMHO I will not be humble anymore in this community it don't work).

Your also correct about implementations as we track that very carefully in the IPv6 Forum and what I believe is happening is folks are implementing what they can "sell" and will be deployed first.  I think IPsec is picking up steam especially around more mission critical early adoption deployment.  Me telling a lady I want to have dinner with her on my 3GGP IPv6 cell phone is simply not mission critical (well hopefully :---)) And I also don't care if its secure either and don't want IPsec slowing down my phone connection to the lady :-----------)

I think it may be we who really care about real IPv6 deployment take this to a new consortia and send it to 3GPP or send it in directly to 3GPP and have them put it as reqs in an appendix and by pass this totally non productive process for this topic.

I do think reducing the scope in title to "current 3GGP UMTS celluar hosts" would be a good political and technical move.

/jim

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2002 11:54 AM
> To: Bound, Jim; [email-masked]; [email-masked]
> Subject: RE: Should DAD be optional? [Was

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 18:40:43 -0500

hey I am all for giving it shot.
/jim

> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2002 3:01 PM
> To: Bound, Jim
> Cc: Margaret Wasserman; [email-masked]
> "Bound, Jim" wrote:
> > UNLESS: We go back to what informational means as Charlie 
> and I believe
> > as it used to be?
> > 
> > I doubt that is possible.
> 
> Well, it's worth a shot, and the draft could include enough
> text to make it obvious what is meant.  That would only make
> a difference to people who bother to even glance at the document,
> but anybody implementing the platform would be likely to see it,
> and any marketing literature would probably not risk the black
> eye of provably misconstruing the document.
> 
> Regards,
> Charlie P.
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 18:43:06 -0500

I don't know about others but I don't support what your ammenable to.
Your watering it down.

I don't want it watered down.

Do it out of the IETF.

/jim

> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2002 3:59 PM
> To: Charles E. Perkins
> Cc: Bound, Jim; [email-masked]
> I'd be amenable some sort of "guidelines" document that offers
> some guidance to 3GPP vendors on which portions of which IPv6
> specifications should be implemented in cellular hosts.  With
> the following characteristics:
> 
>          - The document should clearly state that it is not
>                  a standard, and that it doesn't modify any
>                  other standards.  I know that "informational"
>                  status implies this, but I think it should
>                  be explicit in the document.
>          - The MUST, MAY, SHOULD... wording should be removed.
>          - All conflicts with existing IPv6 standards should be
>                  eliminated.
>          - The document should be re-worked to focus more on
>                  referring cellular implementers to the correct
>                  IPv6 standards.
>          - We should not recommend anything that we don't 
>                  agree with -- for instance, if we think that
>                  IP Sec should be included in all IPv6 hosts,
>                  this document shouldn't say otherwise.
> 
> Margaret
> 
> 
> At 03:01 PM 3/6/02 , Charles E. Perkins wrote:
> >"Bound, Jim" wrote:
> >

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 7 Mar 2002 00:03:39 -0500

Margaret,

OK people want to keep trying. 

> the following characteristics:

I would suggest a set for guidelines for the current 3GGP Release 5
vendors shipping IPv6 for that stated use and keep the focus of the
document as limited as possible. The purpose of the doc is state which
specifications "are most likely to be used" (NOT IMPLEMENTED) by a 3GGP
Release 5 UMTS Cellular Host.  VEry very specific.  Note this is a use
document not a what must, should, or may be implemented. It is truly an
implementation guideline for Release 5.

>                  be explicit in the document.

I suggest that if use the scope and method I state above then this is
not necessary.  What an overview should do is state in better and more
words what I am suggesting above. Not only is not a standard but by its
very nature its not even close to suggesting that in the document.

>          - The MUST, MAY, SHOULD... wording should be removed.

I would keep them in another context why something will or will not be
used in Release 5 and why it will or why not. The doc does this good
enough for me now but I understand 3GPP implementation, how to build a
3GPP product, and the market needs for Rel 5.  So I am at an advantage
and may see more than others so a bit more words I can accept is needed
if it must be reviewed by this working group.

>          - All conflicts with existing IPv6 standards should be

This is a non issue with my approach the entire point is not in
conflict.  The conflict is that all the standards are not needed for
this initial deployment at this time.

>                  referring cellular implementers to the correct

This is a shot at the authors and wrong.  At least thats how I read it.
The authors have the correct standards just saying they are all not
needed for Rel 5.  These authors are some of the most knowledgable
people for 3GGP and IPv6 on the planet.  Give them a break.
This is not an issue no matter how this gets resolved.  But this is the
kind of tone that really wants me to influence these authors to take it
out of the IETF and be done with this discussion.

>                  this document shouldn't say otherwise.

The suggestion above is a recommendation of use not what is implemented
on cellular hosts.

John et al this is about as much as I will compromise from my view.  If
we can't get folks to buy into what I suggest or at least in between
what I suggest and Magarets decree I strongly suggest to you that you
will miss what we know is a time to market issue and you are better off
working this through the ITU, 3GGP, and 3GGP2 and I will go there and am
confident that others from here will too, to support you. 

regards,
/jim

---

From: [email-masked]
Date: Thu, 7 Mar 2002 18:00:17 +0200

Hi Keith,

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

Hopefully noone things that our document is comparible to NATs ;)

My hope is that what we produce is clear, reaches consensus in the
WG and is useful.  I do think that giving assistance on when
some IPv6 signaling is needed and when it is option to use is
a good thing (bounded by consensus with the WG).

thanks,
John