Subject: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt

From: Brian Haberman <[email-masked]>
Date: Wed, 22 Sep 2004 09:49:02 -0400

All,
      This starts a 1 week IPv6 Working Group Last Call on advancing:

          Title           : Optimistic Duplicate Address Detection for 
IPv6
          Author(s)  : N. Moore
          Filename : draft-ietf-ipv6-optimistic-dad-02.txt
          Pages       : 15
          Date	         : 2004-9-9

as a Proposed Standard.  This last call is to ensure that all comments
raised during the initial last call have been addressed.  Substantive
comments should be addressed to the IPv6 mailing list.  The last call
will end on Sept. 29, 2004.

Regards,
Bob & Brian
IPv6 WG co-chairs

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Thu, 23 Sep 2004 12:31:13 +0300 (EEST)

On Wed, 22 Sep 2004, Brian Haberman wrote:
>           Title           : Optimistic Duplicate Address Detection for IPv6
>           Author(s)  : N. Moore

One major comment:
                                                                                                                        
5. Security Considerations

   Further work will be required to integrate Optimistic DAD with Secure
   Neighbor Discovery [SEND].

==> sorry for not saying this earlier, but this seems unacceptable to
me.  SEND specs are already in the RFC-ed queue, and the WG has been
closed.  This IMHO needs to be analyzed here.  I.e., analyze and state
how oDAD interacts (or not) with SEND.  AFAICS, there shouldn't be any
showstoppers here..

.....

A couple of editorial nits/typos:

   There will be no response to its NS (sent from ::), and this NS 
will
 
==> s/::/the unspecified address/ (clearer when used in braces)

   This version of Optimistic DAD is dependant on the details of the
 
==> s/dependant/dependent/

   [MIPV6] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6,
        revision 24 (draft-ietf-mobileip-ipv6-24).  June 2003 ...
        Expired December 2003.

==> now RFC.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Sep 2004 13:58:28 +0300

> how oDAD interacts (or not) with SEND.  AFAICS, there shouldn't be any

I agree with Pekka that it should be covered. But I also
thought that at least an earlier version of the document
already had SEND support...

--Jari

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 24 Sep 2004 07:27:41 +1000

> how oDAD interacts (or not) with SEND.  AFAICS, there shouldn't be any

Okay, I can see that.  I guess SEND ran past me while I wasn't
looking :-)  Would any of the ex-SEND-ites be able to help me 
out by reading the draft and suggesting a short bit of text --
as far as I can tell OptiDAD-02 and SEND-CGA "just works", because
version -02 no longer says anything about how addresses are
generated.

But are there any other SEND messages sent at address configuration
time which might cause harm in the case of an address collision?

> ==> s/dependant/dependent/

No worries.

>         revision 24 (draft-ietf-mobileip-ipv6-24).  June 2003 ...

Argh!  I was sure I'd fixed that one!  

Thanks,

-----Nick

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 24 Sep 2004 07:41:02 +0900

>>>>> On Wed, 22 Sep 2004 09:49:02 -0400, 
>>>>> Brian Haberman <[email-masked]> said:

> will end on Sept. 29, 2004.

I'm not sure if this version addresses the three points below I made
in the previous last call (*)
(*) http://www1.ietf.org/mail-archive/web/ipv6/current/msg03082.html

>>>>> On Fri, 23 Jul 2004 14:39:16 +0900, 
>>>>> JINMEI Tatuya said:

> 1. overall, this approach depends on reasonably small reachable time
>   (per Section 4.2 of RFC2461).  If this value happens to be set to a
>   large value (say, a few to 10 minutes?) via RA, a duplicate
>   link-layer address of an optimistic node can mistakenly be stored
>   for the unreasonaly large period.  While this is a general issue on
>   the reasonable value of reachable time, I think this draft should
>   explicitly note that since it is going to modify the existing
>   protocol and affect implementations.  Perhaps we even need to define
>   the upper limit of reachable that to allow the optimistic behavior.

> 7. In section 2.2

>    Protocols which do not understand this state should
>    treat it equivalently to 'Deprecated', to indicate that the address
>    is available for use but should not be used if another suitable
>    address is available.

> I don't really understand what "protocols which do not understand this
> state" actually means.

> 13. In section 4

>    The ON will immediately send out a Neighbour Solicitation to
>    determine if its new address is already in use, and a Neighbour
>    Advertisement (with the Override flag cleared) for the address. This
>    NA allows communication with neighbours to begin immediately.

> What does "immediately" mean?  Are you saying a random delay before
> the first NS (in some situation) should be removed?  The same comment
> should apply to NA, while I object to sending such NAs in the first
> place (see comment 5 above).

I also have a couple of additional comments on new changes in version
02, which I think can be substantial.

1. In section 2.4:

   Implementing this behaviour may be difficult and unnecessary, so it
   is left as an option to the implementor.

I don't really understand this sentence...what does "this behaviour"
actually specifies?  (Depending on the answer to the previous
question) why implementing it may be difficult and unnecessary?  Or as
a meta-question, is it really adequate to asses whether implementing
something may be difficult or not in a protocol specification?

2. In section 4.2:

   In the course of establishing connections, the ON may send NAs either
   spontaneously or in response to received NSs.

What do you mean by saying "the ON may send NAs spontaneously"?  If
this means unsolicited NAs to all-nodes multicast group, I believe we
decided to remove that feature from the spec.  In fact, no other parts
of the 02 version talk about the unsolicited NAs.  So, if this is the
intent, we should simply remove this part and rewrite the sentence as:

   In the course of establishing connections, the ON may send NAs in
   response to received NSs.

If the intent is not unsolicited NAs, please clarify that.

Finally, I found some editorial nits.  Those are very minor and aren't
a showstopper.  (i.e., if they need to be addresses, it can be done
later with IESG comments.)

3. It's odd to see that the document sometimes say "Optimistic Node"
   or "Optimistic node" even after the introduction of abbreviation
   "ON".  This level of mixture might be acceptable, but I'd prefer
   consistent usage.

4. In section 2.3

   * clearing the 'Override' flag in Neighbor Advertisements for
        Optimistic addresses, which prevents neighbors from overriding
        their existing NC entries. The 'Override' flag is already
        defined [RFC2461] and used for Proxy Neighbor Advertisement.

s/Optimistic addresses/Optimistic Addresses/?

(This seems to be the only occurrence of "optimistic address" with
"address" being not capitalized.)

5. In section 2.3

   * Never using a Optimistic Address as the source address of a Router
        Solicitation with a SLLAO.  Another address, or the unspecified
	...

s/a Optimistic/an Optimistic/

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 24 Sep 2004 11:49:24 +1000

> (*) http://www1.ietf.org/mail-archive/web/ipv6/current/msg03082.html

Hi Jinmei,

	Well, I'm glad it's managed to address the rest of them!

	I'm not sure if I understand your first point, though, because
I thought we'd cleared that up ... it wasn't on your later "big issues"
list ...

> >   the upper limit of reachable that to allow the optimistic behavior.

... stored where, and by who?  Only neighbours actively communicating
with a node SHOULD update their NC entries, and the Optimistic NA (O=0)
won't override them.  There's a tiny window of opportunity for an
Optimistic node with a duplicate address to interfere with a proxy ND
address during address resolution , but this will be sorted out by
NUD anyway.  Can you give me an example of when this will cause a
problem?

> > I don't really understand what "protocols which do not understand this

Would "Implementations of protocols which do not explicitly define
behaviour for Optimistic Addresses should treat them equivalently
to Deprecated Addresses ..." be more or less clear?

(Or if anyone who does understand why I'm trying to say can
suggest some wording, that'd be great ...)

> > place (see comment 5 above).

You're correct on this one, I'd meant to remove the first 'immediately'.
The rest of the text has been changed.

> something may be difficult or not in a protocol specification?

Okay, this section is trying to explain why the fourth rule in 3.1
is only a SHOULD rather than a MUST.  It's basically to cut the
implementor some slack: in a situation (mobile phones come to mind)
where communication is primarily with hosts not on your local
network, there's no need to implement this feature, and the only
penalty is that network-local communications have to wait for
DAD to complete.  It's a compromise between universality and simplicity.

>    response to received NSs.

We agreed that there is no point in mentioning unsolicited NAs 
in OptiDAD, because they are only useful to a tiny minority.
I thought we'd agreed that it wasn't necessary to explicitly
disallow them though.

RFC 2461 7.2.6 says:
|
|   In some cases a node may be able to determine that its link-layer
|   address has changed (e.g., hot-swap of an interface card) and may
|   wish to inform its neighbors of the new link-layer address quickly.
|   In such cases a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT
|   unsolicited Neighbor Advertisement messages to the all-nodes
|   multicast address.  These advertisements MUST be separated by at
|   least RetransTimer seconds.

I guess whether that allows unsolicited NAs on arrival is open to
debate: I'd think of that as a change of LL address from nothing
to something, and a prime example of a time you might wish to inform
your neighbours of your LL address quickly.

Either way, I don't want to override 2461 on this particular thing.

> later with IESG comments.)

Thanks for those, I'll clear them up too.

-----Nick

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Sat, 25 Sep 2004 08:16:39 +1000

>          Filename : draft-ietf-ipv6-optimistic-dad-02.txt

G'day IPv6ers ...

	well, it's bad timing on the Last Call, unfortunately,
because I'm off on vacation for five weeks starting today!
Rhonda and I will be backpacking around in Scotland, Ireland
and Italy, so I won't be reading email much if at all in this
time.  I'm looking forward to the break!

	Draft submission will be closed by the time I get back,
and I won't be able to come to IETF Washington, so we'd better
sort it out on the mailing list!

	So far, it's mostly editorial issues, which I suppose
can be fixed post-LC, including some grammar nits and a couple
of places where I've tried to clarify myself and failed :-|
I'm happy just to make the text changes as per my replies,
if they're acceptable ...
	
	There have been a couple of bigger issues raised which
I think need to be discussed on the list.  I think they're 
fixable with minor changes too:

1: Interoperability with SEND

	The draft points out rather uselessly:
	
		Further work will be required to integrate Optimistic
		DAD with Secure Neighbor Discovery [SEND].

	... but now SEND is complete.  It would be good to address
	any SEND issues in OptiDAD.  I think all that is required is
	for someone who understands SEND better than I do to think
	it through and give it a big rubber stamp so I can change the
	text to:
		
		Optimistic DAD is interoperable with Secure Neighbour
		Discovery [SEND] because ...

	The question is, fundamentally, "does SEND require sending 
	any signals during address configuration which would 
	disadvantage a collidee".  If someone expert in SEND could
	answer this question, I'll change the text!

2: Unsolicited NAs 

	OptiDAD does not disallow the unsolicited NAs mentioned in
	RFC 2461 7.2.6.  It no longer mentions sending them either.

	The only text which does mention them in passing is 4.2,
	which explains:

		In the course of establishing connections, the ON may
		send NAs either spontaneously or in response to received
		NSs.  Since these NAs will have O=0, they will not
		override existing NC entries, although they may result
		in a colliding entry being changed to state STALE.

	... note that that's not MAY, it's just may.  This is in a 
	section explaining the behaviour (4. Protocol Operation),
	not the section listing the rules of OptiDAD (3. Modifications
	to RFC-mandated behaviour).  It's meant to be explaining 
	why sending NA O=0 is mostly harmless.

	Perhaps this would be clearer if I changed 'may send' to 
	'might have sent' (and corresponding tense changes throughout).
	
	Would that be okay, Jinmei?  Does anyone else hold strong
	opinions on this?

	I won't be on email much.  But if the rest of the WG can talk
these issues through a bit, and if necessary orchestrate a consensus
call or something, I'll try and get an ssh session out of an internet
cafe in Edinburgh in a week or so, and make whatever changes are
necessary.

	At this point, I just want to get it into the IESG queue
so I can move on to topics closer to my current research.

cheers,

------Nick

---

From: Francis Dupont <[email-masked]>
Date: Sun, 26 Sep 2004 19:00:49 +0200

In your previous mail you wrote:

=> I have two concerns about the draft:
 - requirement level keywords are used only in section 3 but
   MUST and must have different meanings. As it is clear than
   the section 3 is not equivalent to the whole document, I believe
   this choice is unfortunate...
 - 2.1 talked about "manually assigned" addresses without formal
   definition, for instance the text only suggests RFC 3041 addresses
   are not included in this "manually assigned". BTW the "should"
   in 2.1 is an example of my previous concern.
A comment: even if this version of optimistic DAD seems to be really
compatible with DAD goals, I still believe that in a mobile environment
the network manager should simply disable DAD (i.e., count=0) on all
nodes on application to the KISS principle.

Thanks

[email-masked]