Subject: [DNA] Some questions about Simple DNA

From: Bernard Aboba <[email-masked]>
Date: Fri, 18 Apr 2008 00:08:31 -0700

I was looking over the Simple DNA draft, and had some questions: 

Section 3.3 says:

   All Router Solicitations and unicast Neighbour Solicitations sent for
   DNA purposes while addresses are in optimistic state SHOULD include
   the Tentative Option [4].

I do not believe that DNAv6 implementations should be required to support
Optimistic DAD. Prior to completion of DNAv6, a candidate address can be
considered Deprecated; after successful completion, it can be promoted to
Preferred. 

Why should the Tentative Option be set in a Unicast Neighbor Solicitation?
After all, this is sent to the unicast IPv6 and MAC address of the router, 
not to multicast IPv6/MAC addresses.  Therefore, there is no risk of
cache pollution.  Therefore why not establish the neighbor cache entry
immediately so that incoming packets can be received?  To facilitate
this, the unicast NS packet should be sourced from the candidate address.

Section 3.4 says:

   The Router Solicitation is sent to the All-routers
   multicast address containing one of the host's optimistic unicast
   source address [2][5].  If the host is in possession of more than one
   valid IPv6 address, it MUST send only one router solicitation using
   any one of its valid IPv6 addresses as the source address.

Why is one of the candidate addresses chosen as the source?  Since the router 
MAY respond to this address with a unicast RA, doesn't this risk loss of the
RA if the candidate address chosen isn't appropriate for the network?  
Wouldn't it make more sense for the source to be the unspecified address?
Also, I'd suggest that the RS *not* contain a SLLAO, so as to avoid
cache pollution.

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 18 Apr 2008 18:59:35 -0400

Hi Bernard,
   Thanks for the comments. Please see responses inline.

> this, the unicast NS packet should be sourced from the candidate address.

The Router needs to be able to respond to this unicast NS packet. For 
this it requires the L2 address of the soliciting node. If the node 
includes an SLLAO, it might cause cache pollution if there is another 
node who is currently using the same address on the network. This is why 
we need the TSLLAO.

> Also, I'd suggest that the RS *not* contain a SLLAO, so as to avoid

If we send out an RS with the unspecified source address, this will lead 
to the router sending a multicast RA to the all-nodes address. This 
might have an undesirable side effect of waking up dormant nodes. I do 
not have strong feelings about this, but others might.

Thanks
Suresh

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 18 Apr 2008 17:56:27 -0700

Suresh said:

"The Router needs to be able to respond to this unicast NS packet. For 
this it requires the L2 address of the soliciting node. If the node 
includes an SLLAO, it might cause cache pollution if there is another 
node who is currently using the same address on the network. This is why 
we need the TSLLAO."

By definition, for a host to do DNAv6, it has already completed
duplicate address detection on the address.  Why should the host
be required to do (Optimistic) DAD ever time it awakes from sleep?
Given the duty cycles we are now seeing, this means that the host
will never obtain a usable address!

Suresh said:

"If we send out an RS with the unspecified source address, this will lead 
to the router sending a multicast RA to the all-nodes address. This 
might have an undesirable side effect of waking up dormant nodes. I do 
not have strong feelings about this, but others might."

Unless the RS is sent with the unspecified address, DNAv6 cannot meet its 
goal of being no worse than existing configuration schemes.  Since a host
choosing the "wrong" candidate address may not receive an RA, simple DNA
would very likely suffer a performance degradation compared with existing
schemes.

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 21 Apr 2008 18:28:16 -0400

Hi Bernard,

> will never obtain a usable address!

This is to deal with another host picking up the same address after the 
host went to sleep/left the link. The new host thinks that its address 
is unique while in fact it is not. I do not see any other way around this.

> would very likely suffer a performance degradation compared with existing

I see your point and I agree with you. I will make this change to 
version -01 of the draft.

Thanks
Suresh

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 21 Apr 2008 21:02:17 -0700

> be required to do (Optimistic) DAD every time it awakes from sleep?

[BA] In the case of an address obtained from DHCPv6, where the lease is
still valid, the host had previously done DAD and a compliant DHCPv6 
server will not give out the same address to multiple hosts.  So why 
should the host do DAD again? 

Also, if the host has not been gone from the network more than the
time required for DAD to complete, then it could not have missed a
DAD attempt from another host.  

Therefore I do not see a reason why a mobile host that is moving
between points of attachment on the same LAN should be required to
do DAD each time it connects to a new AP.

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 28 Apr 2008 14:37:55 -0400

Hi Bernard,

> should the host do DAD again? 

I am fine with the host not doing DAD in this case. I think that this is 
bringing out is that there is a difference based on whether the address 
was statelessly autoconfigured or acquired through DHCP.

* Address was acquired through DHCPv6 : Server does not give out the 
address to anyone else and hopefully a router is not advertising the 
same prefix as available for SLAAC. In this case it is fine to skip the DAD.

* Address was configured using SLAAC : Nobody is keeping track of the 
address used by the node. In this case when the node gets back into the 
link, it needs to do DAD.

Is this an acceptable bifurcation?

Thanks
Suresh

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 28 Apr 2008 17:36:44 -0700

> * Address was configured using SLAAC : Nobody is keeping track of the > address used by the node. In this case when the node gets back into the > link, it needs to do DAD.> > Is this an acceptable bifurcation?
Not completely.  If the host is only gone from the link for a small period (e.g. enough to complete a handoff), then I don't see why DAD should be required, since enough time would not have elapsed to allow another host to complete DAD for the same address.
 
Also, longer absences are similar in the effect of network partitioning and healing, where two hosts can each complete DAD, and therefore come to believe that their addresses are unique.  Yet when their previously partiioned networks are joined, they can discover conflicts.  Therefore the problem of ongoing conflict detection exists in either scenario.

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 29 Apr 2008 23:37:32 +1000

On 29/04/2008, at 10:36 AM, Bernard Aboba wrote:

> Not completely.  If the host is only gone from the link for a small  
> period (e.g. enough to complete a handoff), then I don't see why DAD  
> should be required, since enough time would not have elapsed to  
> allow another host to complete DAD for the same address.
>
> Also, longer absences are similar in the effect of network  
> partitioning and healing, where two hosts can each complete DAD, and  
> therefore come to believe that their addresses are unique.  Yet when  
> their previously partiioned networks are joined, they can discover  
> conflicts.  Therefore the problem of ongoing conflict detection  
> exists in either scenario.

=> Yes but DAD was never intended to address the problem of network  
partitioning/joining. So this problem is outside the scope of DAD.

Hesham

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 29 Apr 2008 19:37:48 -0400

Hi Bernard,

Bernard Aboba wrote:
> should be required, since enough time would not have elapsed to allow 
> another host to complete DAD for the same address.

In order to do this we need to keep track of how long the host has been 
gone from the link. And since the DAD transmits and timeouts are based 
on host specific configuration, it might be very hard to come up with a 
decent borderline number on the amount of time elapsed away from the 
link when the host needs to start doing DAD.

>  
> Also, longer absences are similar in the effect of network partitioning 
> and healing, where two hosts can each complete DAD, and therefore come 
> to believe that their addresses are unique.  Yet when their previously 
> partiioned networks are joined, they can discover conflicts.  Therefore 
> the problem of ongoing conflict detection exists in either scenario.

Agree.

Thanks
Suresh

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Apr 2008 17:54:50 -0700

>link when the host needs to start doing DAD.

This could be accomplished by tracking the time that has elapsed since 
receipt of a "link down" indication.  This could be included with the
configuration data associated with a given router. 

That way, when the reachability test completes, the host would check
the elapsed time since "link down" against a host-configured parameter 
in order to decide whether to do Optimistic DAD.

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 30 Apr 2008 08:18:01 +0200

Even if the host is away from the link for only 1 ms, it could miss the DAD as another host might send its DAD probe during this 1 ms period. Is it assumed that the DAD probe is buffered by the network and delivered to the host upon re-attachment?

domagoj

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Bernard Aboba
> Sent: 30. travanj 2008 02:55
> To: 'Suresh Krishnan'
> Cc: [email-masked]
> Subject: RE: [DNA] Some questions about Simple DNA
> 
> This could be accomplished by tracking the time that has 
> elapsed since receipt of a "link down" indication.  This 
> could be included with the configuration data associated with 
> a given router. 
> 
> That way, when the reachability test completes, the host 
> would check the elapsed time since "link down" against a 
> host-configured parameter in order to decide whether to do 
> Optimistic DAD. 
> 
> 
> 
>