Re: [dhcwg] Question on DHCPv6 Draft 23.

RE: [dhcwg] Question on DHCPv6 Draft 23.Hi Bernie,

thank you for your prompt reply.

I am much clearly now as to the purpose of the SOLICIT/ADVERTISE and REQUEST/REPLY sequence.

Bernie, are there any implementations working towards the latest draft ? I managed to find some codes (e.g. kame DHCP, isc DHCPv6), but I found that they don't really support the draft's specificaton.

Paul
  ----- Original Message ----- 
  From: Bernie Volz (EUD) 
  To: Paul Tan ; dhcwg@ietf.org 
  Sent: Thursday, March 21, 2002 5:47 AM
  Subject: 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 