RE: [dhcwg] Question on DHCPv6 Draft 23.

Paul:

See comments below, prefixed by BV>.

- Bernie

-----Original Message-----
From: Paul Tan [mailto:tanpaul@cwc.nus.edu.sg]
Sent: Wednesday, March 20, 2002 1:54 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Question on DHCPv6 Draft 23.

Hi all,

we are currently trying to implement a DHCPv6 client/server (draft 23) in
Linux environment. Are there any active implementations working on the
latest DHCP draft 23 ?

I have a few questions concerning the DHCPv6 draft 23.

1) After a client sends out a SOLICIT with an IA option attached (no IA Addr
Opt), the server will basically reply with an ADVERTISE message with some
addresses attached in the IA Addr options.

- Does the lifetime for this IA starts after the server sends the ADVERTISE
message ? How does the server knows whether if the client has decided to use
the address advertised by this server, when in fact the client has chosen
some other server ?

BV> The lifetimes in the Advertise are in one sense meaningless since there
BV> is no contract between client and server regarding these. Only after the
BV> Request/Reply sequence can a client use the addresses and do the lifetimes
BV> apply. The lifetimes in the Advertise, IMHO, should be the ones the server
BV> INTENDS to give the client in a future Reply should the client chose the
BV> server. If the server does take steps to reserve the addresses for the
BV> client, it may actually do this with a much shorter lifetime. But that is
BV> not what it sends to the server.
BV>
BV> The lifetimes apply based on when the client RECEIVES the message, not
BV> when the server sent it (since the client has no way of knowing this).
BV> This also typically means a server has a small grace period that it
BV> applies to "extend" the lifetimes to allow for a small difference in
BV> the times between client and server (note also that clock speeds on
BV> systems may vary slightly as well). But, the T1/T2 times should also be
BV> choosen by servers to allow plenty of time for renewals.

2) When the client receives the ADVERTISE message, it will attempt to
configure its interface with the assigned address from the list of server's
ADVERTISE messages.
BV> NO!!! You can not do this until after the Request/Reply sequence!!!!
- Does it need to send a REQUEST message immediately after the ADVERTISE
message to confirm that the client is using the address from a particular
server?
- What is the main purpose of the REQUEST message ? Get the configuration
info of a particular IA ?
BV> It is to get the actual address assignments and configuration. Information
BV> that is received in the Advertise is only an advertisement for service and
BV> not an offer for server.
BV> The Solicit/Advertise is a way for a client to determine what servers are
BV> likely to offer it. BUT, the Requeset/Reply is the actual negotiation of
BV> what the client gets.
BV> Think of this as advertisements you get in the mail. They are to bring you
BV> in to the store. But, you actually have to buy something to take advantage
BV> of the advertisements. That is the Request/Reply phase.

3) I'm a bit confused with the following paragraph in the draft...
- ... if the server will not assign any addresses to IAs in a subsequent
REQUEST from the client, the server SHOULD either send an ADV message to the
client that includes only a status code option (AddrUnavail) for the user or
not respond to the SOLICIT message....
BV> What's are you confused about regarding this? I think my above comments
BV> make it clear that the Request/Reply is the real assignment phase and not the
BV> Solicit/Advertise. Hence the text should be clearer with that understanding?

BV> NOTE: I am a bit concerned by this misunderstanding - perhaps we're not clear
BV> enough in the -23 draft with regard to the entire DHCPv6 sequence (we may
BV> often be assuming too much since we know all about it and forget to write it
BV> for people who haven't been working on the draft).

Thank you for your kind attention.

Regards,
Paul
Institute for Communications Research

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg