RE: [dhcwg] Question on DHCPv6 Draft 23.
"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Thu, 21 March 2002 01:58 UTC
Received: from optimus.ietf.org (ietf.org [126.96.36.199] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21451 for <firstname.lastname@example.org>; Wed, 20 Mar 2002 20:58:11 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA28539 for email@example.com; Wed, 20 Mar 2002 20:58:14 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28401; Wed, 20 Mar 2002 20:53:26 -0500 (EST)
Received: from ietf.org (odin [188.8.131.52]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28320 for <firstname.lastname@example.org>; Wed, 20 Mar 2002 20:53:21 -0500 (EST)
Received: from imr1.ericy.com (imr1.ericy.com [184.108.40.206]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21401 for <email@example.com>; Wed, 20 Mar 2002 20:53:18 -0500 (EST)
Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [220.127.116.11]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2L1rKl06391 for <firstname.lastname@example.org>; Wed, 20 Mar 2002 19:53:20 -0600 (CST)
Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [18.104.22.168]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g2L1rKP07385 for <email@example.com>; Wed, 20 Mar 2002 19:53:20 -0600 (CST)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Mar 20 19:53:19 2002 -0600
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <ZP04CNSC>; Wed, 20 Mar 2002 19:53:19 -0600
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: 'Paul Tan' <firstname.lastname@example.org>, "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
Subject: RE: [dhcwg] Question on DHCPv6 Draft 23.
Date: Wed, 20 Mar 2002 19:53:17 -0600
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D07B.2B8277D0"
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:email@example.com] Sent: Wednesday, March 20, 2002 8:28 PM To: Bernie Volz (EUD) Cc: firstname.lastname@example.org 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:Bernie.Volz@am1.ericsson.se> To: Paul Tan <mailto:email@example.com> ; firstname.lastname@example.org <mailto:email@example.com> 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:firstname.lastname@example.org <mailto:email@example.com> ] Sent: Wednesday, March 20, 2002 1:54 AM To: firstname.lastname@example.org <mailto:email@example.com> 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 firstname.lastname@example.org https://www1.ietf.org/mailman/listinfo/dhcwg <https://www1.ietf.org/mailman/listinfo/dhcwg>
- RE: [dhcwg] Question on DHCPv6 Draft 23. Bernie Volz (EUD)
- Re: [dhcwg] Question on DHCPv6 Draft 23. Paul Tan
- RE: [dhcwg] Question on DHCPv6 Draft 23. Bernie Volz (EUD)