RE: [dhcwg] Question on DHCPv6 Draft 23.

["Bernie Volz (EUD)" <[e-mail]>]

Paul:
 
I know there are people implementing this draft. I assume if they want to make that public or have an implementation they're willing to make available, they will respond independently.
 
- Bernie

-----Original Message-----
From: Paul Tan [mailto:[e-mail]]
Sent: Wednesday, March 20, 2002 8:28 PM
To: Bernie Volz (EUD)
Cc: [e-mail]
Subject: 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) <mailto:[e-mail]>  
To: Paul Tan <mailto:[e-mail]>  ; [e-mail] <mailto:[e-mail]>  
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:[e-mail] <mailto:[e-mail]> ] 
Sent: Wednesday, March 20, 2002 1:54 AM 
To: [e-mail] <mailto:[e-mail]>  
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 
[e-mail] 
https://www1.ietf.org/mailman/listinfo/dhcwg <https://www1.ietf.org/mailman/listinfo/dhcwg>