Subject: RE: [dhcwg] Using DHCP to do link-local DAD?

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 16 Jun 2006 14:25:26 -0400

While there isn't an explicit prohibition in 3315 regarding link-local
addresses that I can recall, I'm not sure how this can solve the problem
and even work. The client REQUIRES a link-local address to send IPv6
datagrams to the DHCPv6 server (or relay). The relay or server needs
this to be able to send the response back to the client.

- Bernie 

> -----Original Message-----
> From: Templin, Fred L [mailto:[email-masked]] 
> Sent: Friday, June 16, 2006 12:10 PM
> To: [email-masked]
> Subject: [dhcwg] Using DHCP to do link-local DAD?
> 
> Another DHCP question. Suppose a set of DHCP clients
> and relay/servers were connected to a "limited broadcast,
> multiple access" link in which a DHCP client's broadcasts
> are heard by some nodes on the link but not necessarily
> all nodes. In that case, when a client node configures
> a link-local address and sends NS(DAD) per (RFC2462,
> Section 5.4) the client might fail to detect another
> node on the link with a duplicate link-local address.
> 
> Is it possible to use DHCP to instate a DHCP-based
> link-local DAD policy and procedure on such a link?
> What I have in mind is:
> 
>   1) Client configures a link-local address and marks
>      it as tentative per RFC2462.
>   2) (Assuming for now two-message exchange) client sends
>      a DHCP SOLICIT to 'All_DHCP_Relay_Agents_and_Servers'
>      with source address set to the tentative link-local
>      address and the SOLICIT contains an IA Address option
>      that also encodes the tentative link-local address.
>   3) Server receives the SOLICIT and checks to see if the
>      address encoded in the IA option can be assigned to
>      the client.
>   4) Server sends a REPLY back to the client with a status
>      code in the IA Address option telling whether/not the
>      tentative addess could be assigned.
>   5) If the status code indicates success, the client claims
>      the link-local address and assigns it to an interface.
>      If the status code indicates failure, the client either
>      discards the address and tries again with a different
>      tentative link-local or it disables the interface.
>   6) If the tentative address was actually a duplicate, the
>      server's REPLY message might be sent to the true owner
>      of the link-local address instead of the client that
>      sent the SOLICIT. But, the true owner would discard the
>      REPLY because the DUID and/or Transaction ID would be
>      unrecognized. In that case the client that sent the
>      SOLICIT would not receive the REPLY and would time out
>      and assume the address was a duplicate.
> 
> Comments?
> 
> Fred
> [email-masked]
> 
>  
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 16 Jun 2006 11:35:17 -0700

Bernie, 

> this to be able to send the response back to the client.

Right; I was thinking that the client could use its tentative
link-local address as the source address in the DHCP messages
it sends to the server. Then, the server would have a return
address for the messages it sends back to the client.

If the client's tentative link-local address happens to be
in-use by a different node, then: a) the client's DHCP messages
will never reach the server, and the client will timeout, or
b) the server's DHCP messages will be incorrectly forwarded
to the true owner of the link-local address where they will
be harmlessly dropped, and again the client will timeout.

Does this clarify?

Thanks - Fred

- Bernie