Subject: [dna] #17: DHCP and ND probes complete with different results

From: "dna issue tracker" <[email-masked]>
Date: Wed, 16 Sep 2009 14:40:18 -0000

#17: DHCP and ND probes complete with different results
------------------------------------------+---------------------------------
 Reporter:  [email-masked]  |       Owner:  Suresh Krishnan
     Type:  defect                        |      Status:  new            
 Priority:  major                         |   Milestone:                 
Component:  simple                        |     Version:                 
 Severity:  Active WG Document            |    Keywords:                 
------------------------------------------+---------------------------------
 The draft needs to mention what happens if the DHCPv6 and ND probes
 complete with different results and mention what results take precedence.

 Submitters: Bernard Aboba, Jari Arkko

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/dna/trac/ticket/17>
dna <http://tools.ietf.org/dna/>

---

From: "dna issue tracker" <[email-masked]>
Date: Wed, 16 Sep 2009 18:35:34 -0000

#17: DHCP and ND probes complete with different results
------------------------------------------+---------------------------------
 Reporter:  [email-masked]  |        Owner:  Suresh Krishnan
     Type:  defect                        |       Status:  closed         
 Priority:  major                         |    Milestone:                 
Component:  simple                        |      Version:                 
 Severity:  Active WG Document            |   Resolution:  fixed          
 Keywords:                                |  
------------------------------------------+---------------------------------
Changes (by [email-masked]):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 I propose adding the following section to resolve this issue.

 4.7.1.  Conflicting results

    It is possible that the DHCPv6 based probes and the neighbor
    discovery based probes complete with conflicting results.  In this
    case, the host SHOULD use the following rules to determine the final
    result.

    o  If the DHCPv6 exchange was authenticated, use the result from the
       DHCPv6 probe.

    o  If the DHCPv6 exchange was not authenticated and the neighbor
       discovery exchange was protected by SEND [RFC3971], use the result
       from the neighbor discovery probe.

    o  If both the DHCPv6 and neighbor discovery exchanges were not
       authenticated, use the result from the DHCPv6 probe

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/dna/trac/ticket/17#comment:1>
dna <http://tools.ietf.org/dna/>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 16 Sep 2009 11:43:17 -0700

>        from the neighbor discovery probe.

What if the RA (protected by SEND) no longer announces a prefix and indicates that DHCPv6 is now used for address assignment.  Should the host not use the address assigned by DHCPv6 and instead use the address formed as the result of a (no longer advertised) prefix?

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 16 Sep 2009 15:16:35 -0400

Hi Bernard,

On 09-09-16 02:43 PM, Bernard Aboba wrote:
> What if the RA (protected by SEND) no longer announces a prefix and 
> indicates that DHCPv6 is now used for address assignment.  Should the 
> host not use the address assigned by DHCPv6 and instead use the address 
> formed as the result of a (no longer advertised) prefix?

In this case the neighbor discovery probe will conclude with the result 
that there has been a link change (since the prefix is no longer 
advertised). So the host will conclude that neither of these addresses 
are usable on the link.

Thanks
Suresh