From listproc@bucknell.edu Mon Sep 18 21:59:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23794 for ; Mon, 18 Sep 2000 21:59:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8J1xCb18275; Mon, 18 Sep 2000 21:59:12 -0400 (EDT) Message-Id: <200009190159.e8J1xCb18275@mail.bucknell.edu> Date: Mon, 18 Sep 2000 21:59:11 EDT Reply-To: listproc@bucknell.edu Sender: listproc@bucknell.edu From: "Bucknell List Processor" To: dhcipv6-archive@ietf.org Cc: droms@bucknell.edu Subject: SUBSCRIBE DHCP-V6 IETF archive X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Dear user, Your request SUBSCRIBE DHCP-V6 IETF archive has been successfully processed. ********** HOW TO POST TO THE LIST ********** Welcome to list DHCP-V6 (dhcp-v6@bucknell.edu). The system has recorded your address as dhcipv6-archive@lists.ietf.org and it is required that you send your postings from this address. ********** HOW TO GET OFF THE LIST ********** To sign off from the list, email to listproc@bucknell.edu with the following request: signoff DHCP-V6 or unsubscribe DHCP-V6 ********** GETTING YOUR SUBSCRIPTION ATTRIBUTES ********** You may get your current subscription attributes at any time by sending the following request to listproc@bucknell.edu: query DHCP-V6 ********** WHERE TO SEND EMAIL ********** If you want to post messages to list DHCP-V6, you should direct your email to dhcp-v6@bucknell.edu, not listproc@bucknell.edu. If you wish to send requests please do not send them to the list -- they will not be processed. Instead direct them to listproc@bucknell.edu. Requests sent to listproc@bucknell.edu should be placed in the body of the email message, not the Subject:. ListProc ignores requests in the Subject: field. You can, however, put as many requests as you like in one mail message; each request should be on a line by itself. If your request is too long for your mailer to handle, you can break it in multiple lines, but each line should end with the character & (ampersand). For example, here are two separate requests: set DHCP-V6 & mail & ack help The ampersands in the above example are immediately followed by carriage returns. The above requests are equivalent to: set DHCP-V6 mail ack help ********** DIGESTS ********** All messages posted to this list are also available in daily digests. If you wish to receive messages in digest format you may send the following request to listproc@bucknell.edu: set DHCP-V6 mail digest ********** LIST OWNERS ********** The list owner's address is dhcp-v6-request@bucknell.edu. You should send e-mail to that address if there are any problems. ********** YOUR LISTPROC PASSWORD ********** The system has assigned you an initial password: 969328751 You may change it by sending the following request to listproc@bucknell.edu: set DHCP-V6 password 969328751 new-password where new-password is the new string of characters that you would like to use as your ListProc password. WARNING: You should NOT use your login password as this is not a secure mechanism. This password is to be used when connecting to this server over the Internet for interactive processing of requests (send a 'help live' request for more information) Statistics for this list are available to privileged users (e.g. owners) only. ********** REVIEWING THE LIST ********** To review the list's settings you may send the following request to listproc@bucknell.edu: review DHCP-V6 ********** ACCESS TO THE LIST'S ARCHIVES ********** The list is regularly archived to the Web and many, if not all, previous postings are available at the following URL: http://www.listproc.bucknell.edu/cgi-bin/archdex?list=dhcp-v6 You can also retrieve archives via commands sent to the list server. Past messages are collected into monthly logs; to get a list of the available logs for this list, you can send the following request to listproc@bucknell.edu: index DHCP-V6 Each line will show you the log file's name, its size, and a brief comment. You can then get any logs with the GET request. For example, if you wish to get log199611 you can send the following request to listproc@bucknell.edu: get DHCP-V6 log199611 Here we assume log199611 is the name of the log. ********** HOW TO GET MORE HELP ********** To get more information on how to use this service, please send the following request to listproc@bucknell.edu: HELP There are far more options, settings, and niceties about ListProcessor(tm) and we encourage you to explore all of them; HELP should be your starting point. Enjoy! ListProcessor(tm) The amount of acknowledgement you wish to receive from this list upon completion of a mailing operation can be changed by means of a "SET DHCP-V6 MAIL option" command, where "option" may be either "ACK" (mail acknowledgement) or "NOACK": SET DHCP-V6 MAIL ACK SET DHCP-V6 MAIL NOACK If you prefer to receive messages from DHCP-V6 in one fell swoop, you may use the the DIGEST option to have DHCP-V6 messages accumulated into digests which will be periodically sent to you: SET DHCP-V6 MAIL DIGEST If you wish to stop delivery of list messages temporarily without unsubscribing from the list, you can use the POSTPONE option: SET DHCP-V6 MAIL POSTPONE When you're ready to receive messages again, use the ACK or NOACK options as described above. To issue any of these commands, send them in the body of a message to the LISTSERV@BUCKNELL.EDU e-mail address. Contributions sent to this list are automatically archived. You can obtain a list of the available archive files by sending an "INDEX DHCP-V6" command to LISTSERV@BUCKNELL.EDU. These files can then be retrieved by means of a "GET DHCP-V6 filetype" command. To post an article to the list, send your message to the list address DHCP-V6@BUCKNELL.EDU. To leave the list at any time, you can send an e-mail message to LISTSERV@BUCKNELL.EDU with the body of your message containing the line: UNSUBSCRIBE DHCP-V6 Virtually, The LISTSERVer at Bucknell From owner-dhcp-v6@bucknell.edu Tue Sep 19 01:47:00 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02518; Tue, 19 Sep 2000 01:47:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8J5i1b04419; Tue, 19 Sep 2000 01:44:05 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8J5i0b04407 for ; Tue, 19 Sep 2000 01:44:00 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a40.pm3-32.theriver.com [206.102.192.104]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id TAA05085 for ; Sun, 17 Sep 2000 19:08:26 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8J5gNw09441 for ; Mon, 18 Sep 2000 22:42:24 -0700 (MST) Message-Id: <200009190542.e8J5gNw09441@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: renewal time In-Reply-To: Message from Jim Bound of "Mon, 18 Sep 2000 21:14:04 -0400." <200009190114.VAA0000771501@anw.zk3.dec.com> Date: Mon, 18 Sep 2000 22:42:23 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Correct new lease-times or the Server could not give the client an > address back meaning its expired too. But no new addresses. Well, but if we're renumbering, the server might well give back a "new address", right? I think the point is that that client isn't asking the server to do this - it's asking the server to renew. _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Sep 19 09:12:24 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14869; Tue, 19 Sep 2000 09:12:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JD9Wb05061; Tue, 19 Sep 2000 09:09:32 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JD9Mb15411 for ; Tue, 19 Sep 2000 09:09:22 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (sj-dial-3-212.cisco.com [171.68.180.213]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA06182 for ; Tue, 19 Sep 2000 09:09:05 -0400 (EDT) Message-Id: <4.3.1.2.20000919060451.00b811c0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 19 Sep 2000 06:07:49 -0700 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: renewal time In-Reply-To: <200009190542.e8J5gNw09441@grosse.bisbee.fugue.com> References: <200009190114.VAA0000771501@anw.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've been thinking of the action associated with renewal as the client asking the server "Tell me what addresses are in this IA now and how long I can use them". If the preferred/valid times have changed, it's like a lease extension. If a renumbering event is in progress, the server can assign new addresses. In any event, the server - based on all the information the server has about the client - is informing the client of the addresses currently in the IA - Ralph At 10:42 PM 9/18/00 -0700, Ted Lemon wrote: > > Correct new lease-times or the Server could not give the client an > > address back meaning its expired too. But no new addresses. > >Well, but if we're renumbering, the server might well give back a "new >address", right? I think the point is that that client isn't asking >the server to do this - it's asking the server to renew. From owner-dhcp-v6@bucknell.edu Tue Sep 19 09:38:08 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15345; Tue, 19 Sep 2000 09:38:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JDbcb06106; Tue, 19 Sep 2000 09:37:38 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JDbTb25391 for ; Tue, 19 Sep 2000 09:37:29 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (sj-dial-3-212.cisco.com [171.68.180.213]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA09788 for ; Tue, 19 Sep 2000 09:37:11 -0400 (EDT) Message-Id: <4.3.1.2.20000919062909.00ae96e0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 19 Sep 2000 06:39:34 -0700 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: DHCPv6 address model proposal... In-Reply-To: <200009160710.e8G7AMH10792@grosse.bisbee.fugue.com> References: <200009160057.UAA0000833649@anw.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Let me see if I can successfully summarize the address model we've been discussing: DHCP clients and servers will use Identity Associations (IAs) to manage IPv6 addresses. Each IA will have: * a unique identifier * a set of IPv6 addresses * a renewal time Clients and servers use the unique identifier to identify the IAs in protocol messages. Each IPv6 has an associated preferred and valid lifetime. The lifetimes are determined by the server and handed to the client. There are no restrictions on the scopes or number of IPv6 addresses in an IA; an IA might contain just one IPv6 address or it might contain a collection of global-, site- and link-local addresses. The renewal time defines the time at which the client must contact the server to get the current state of the IA (call this "renewing" the IA). The renewal time is independent of the address lifetimes of any of the lifetimes of the IPv6 addresses in the IA. It makes most sense for the renewal time to be less than the valid lifetimes of all of the IPv6 addresses in the IA. When the client renews an IA, the server tells the client about the current set of IPv6 addresses in the IA. The server may change the set of addresses or the lifetimes of existing addresses during this renewal. For example, setting a longer lifetime on an address already in the IA is the equivalent of extending the lease on a DHCPv4-managed address. Leaving an address out of an IA marks it immediately as no longer valid for the client. Adding a new address to the IA can be used for renumbering. In any event, the server is authoritative about the set of addresses and lifetimes in the IA. - Ralph At 09:10 PM 9/15/00 -0700, you wrote: > > OK but why is that different than the valid lifetime? In IPv6 if the > > valid timer goes off the connection gets broken. > >The identity association's renewal time is a construct, based on a >process of aggregating all the preferred times (probably) for all the >addresses in an identity association. It exists so that you don't >have to renew addresses seperately, and secondarily so that you don't >send pointless renewal messages for non-renewable addresses. > > > I just want to be sure we have not maybe solved this timer problem with > > the valid lifetime for an address. > >I don't think so - the valid timer serves the purpose of making sure >that an address stops being used once it becomes invalid, and the >renewal timer causes renewal packets to be generated - two different, >albeit related, purposes. > > > But then we could say the renewal time is for the address set in total? > >Precisamento! :') > > > I can live with the client sending back all addresses when it wants to > > renew the global address and that will work with the existing IPv6 > > Address Extension. It does add extra bytes to the message and I think > > we need to at least acknowledge that to a mobile node until we see 156kb > > pedestrian throughput for mobile roaming there is a point where we do > > need to reduce the bytes we won't see those speeds as I read the Tea > > Leaves for Wireless till 2003 as a note. > > > > I think it fair to ask the WG how they feel about this? > > > > Do we try to save bytes for mobile nodes in DHCPv6? I think we should > > if its not too complex to implement which is the engineering trade-off. > >I think if you do the math it's not the clear cut, *particularly* for >a mobile node. Let's say for simplicity (so we have to only talk >about one identity association) that you have a mobile node that's not >doing mobile IP - it's just changing its address from time to time as >it moves around, and doing short-lived transactions on the network. >And right now you're sitting in your office with it. Let's say you >get a global address and a site-local address, and the server is >giving the global address a renewal time of 24 hours, but the site- >local address has a renewal time of a week. So if you renew >addresses together, over a week period, you get this: > >T+0d00h: DHCPsolicit+DHCPadvertise+DHCPrequest+DHCPreply >T+0d12h: DHCPrequest+DHCPreply >T+1d00h: DHCPrequest+DHCPreply >T+1d12h: DHCPrequest+DHCPreply >T+2d00h: DHCPrequest+DHCPreply >T+2d12h: DHCPrequest+DHCPreply >T+3d00h: DHCPrequest+DHCPreply >T+3d12h: DHCPrequest+DHCPreply >T+4d00h: DHCPrequest+DHCPreply >T+4d12h: DHCPrequest+DHCPreply >T+5d00h: DHCPrequest+DHCPreply >T+5d12h: DHCPrequest+DHCPreply >T+6d00h: DHCPrequest+DHCPreply >T+6d12h: DHCPrequest+DHCPreply >T+7d00h: DHCPrequest+DHCPreply > >So you have 1 DHCPsolicit, 1 DHCPadvertise, 15 DHCPrequests and 15 >DHCPreplies. So using the current IP Address extension, each >DHCPreply contains 64 octets of address extensions, plus a minimal >IPv6 header of what, maybe 40 octets, 8 octets of UDP header, and >maybe 16 octets of framing, plus maybe another 64 octets of other >extensions, plus a 16-octet signature, for a total of 208 octets. The >DHCPrequests, I'm not so sure about, but I'm not convinced that it is >going to be usual in a situation like this for them to contain >explicit address requests, so let's say they're more like 64 octets of >header, 16 octets of extensions and 16 octets of signature, for a >total of 96 octets. The DHCPsolicit is probably roughly the same size >as the DHCPrequest - 96 octets. The DHCPadvertise might be as large >as the DHCPreply - 208 octets. So you have 16 208-octet packets and >16 96-octet packets. So the total traffic size in this scenario is >4864 bytes. > >Now consider your scenario - we have: > >T+0d00h: DHCPsolicit+DHCPadvertise+DHCPrequest+DHCPreply for both addresses >T+0d12h: DHCPrequest+DHCPreply for global >T+1d00h: DHCPrequest+DHCPreply for global >T+1d12h: DHCPrequest+DHCPreply for global >T+2d00h: DHCPrequest+DHCPreply for global >T+2d12h: DHCPrequest+DHCPreply for global >T+3d00h: DHCPrequest+DHCPreply for global >T+3d12h: DHCPrequest+DHCPreply for global >T+4d00h: DHCPrequest+DHCPreply for global >T+4d12h: DHCPrequest+DHCPreply for global >T+5d00h: DHCPrequest+DHCPreply for global >T+5d12h: DHCPrequest+DHCPreply for global >T+6d00h: DHCPrequest+DHCPreply for global >T+6d12h: DHCPrequest+DHCPreply for global >T+7d00h: DHCPrequest+DHCPreply for global and site-local > >So here you have one DHCPsolicit, one DHCPadvertise, 15 DHCPrequests >and two DHCPreplies that are the same size as in the previous >scenario, for 16x96+3x208. Plus, you have 13 DHCPreplies that are >174 bytes, so this adds up to a total of 4422 bytes. > >So the actual difference in traffic here is 442 bytes - about 10%. >And this is the *worst case scenario*, which you will almost never see >in the context of a roaming device in the real world. It has a >site-local and global address with very different lifetimes, which is >unlikely in a mobile phone context in the first place. It didn't >move around, so you didn't have to renew because of cell transitions. >If we'd been renewing on cell transitions, there's a good chance we >would have seen the same number of bytes in both cases, because the >renewals would have happened before either lifetime expired. > >So I think in the real world, with a mobile device like a cell phone, >you are going to see no difference in bandwidth consumption. >Furthermore, the worst-case scenario I described is susceptible to >compression, and we might well want to specify a compression mechanism >for low-bandwidth mobile devices anyway. This would probably burn >that 10% down to 1% - an "I didn't move" renewal is going to have a >tiny payload in both directions. > >So I really think that the bandwidth argument isn't a good argument >against this scheme. > > _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Sep 19 11:49:49 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18269; Tue, 19 Sep 2000 11:49:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JFkSb13892; Tue, 19 Sep 2000 11:46:28 -0400 (EDT) Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JFkMb24362 for ; Tue, 19 Sep 2000 11:46:23 -0400 (EDT) Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345) id D30382529; Tue, 19 Sep 2000 10:46:05 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 62D79156C for ; Tue, 19 Sep 2000 10:46:05 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id LAA0000539338; Tue, 19 Sep 2000 11:46:04 -0400 (EDT) From: Jim Bound Message-Id: <200009191546.LAA0000539338@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-reply-to: Your message of "Tue, 19 Sep 2000 06:39:34 PDT." <4.3.1.2.20000919062909.00ae96e0@mail.bucknell.edu> Date: Tue, 19 Sep 2000 11:46:04 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >The renewal time defines the time at which the client must contact the >server to get the current state of the IA (call this "renewing" the >IA). The renewal time is independent of the address lifetimes of any of >the lifetimes of the IPv6 addresses in the IA. It makes most sense for the >renewal time to be less than the valid lifetimes of all of the IPv6 >addresses in the IA. SHould be less than the preferred times. >When the client renews an IA, the server tells the client about the current >set of IPv6 addresses in the IA. The server may change the set of >addresses or the lifetimes of existing addresses during this renewal. For >example, setting a longer lifetime on an address already in the IA is the >equivalent of extending the lease on a DHCPv4-managed address. Leaving an >address out of an IA marks it immediately as no longer valid for the >client. Adding a new address to the IA can be used for renumbering. In >any event, the server is authoritative about the set of addresses and >lifetimes in the IA. Have to watch for DOS attacks as in IPv6 Stateless where router sends zero valid lifetimes with Router Advertisement. Also if a server does not return an address which may have valid lifetime left and telnet running the connection will be broken as a note. regards, /jim From owner-dhcp-v6@bucknell.edu Tue Sep 19 18:18:32 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25618; Tue, 19 Sep 2000 18:18:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JMDMb02233; Tue, 19 Sep 2000 18:13:24 -0400 (EDT) Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JMDEb28297 for ; Tue, 19 Sep 2000 18:13:14 -0400 (EDT) Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA12450 for ; Tue, 19 Sep 2000 15:12:49 -0700 (PDT) Date: Tue, 19 Sep 2000 15:12:49 -0700 (PDT) From: Indrajanti Sukiman To: DHCPv6 discussion list Subject: Q on DHCPv6 draft (draft-ietf-dhc-dhcpv6-15.txt) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In the draft-ietf-dhc-dhcpv6-15.txt, in sections related to message validation (section 11.1, 11.2, 11.3), there are 'MUST' requirements that agents (server and relay) discard messages which do not contain a 'valid link-local address'. My question is, what is the definition of 'a not valid link-local address'? Or, in other words, how would agents perform this verification ? As far as I can tell, RFC2462 defines an invalid link-local address as an address whose valid lifetime has expired. If this is the definition intended, is there a way e.g. for a DHCPv6 server to know the valid lifetime of the link-local address of a remote (several hops away) DHCPv6 client ? Thank you. -- Indrajanti Sukiman From owner-dhcp-v6@bucknell.edu Tue Sep 19 18:31:37 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25780; Tue, 19 Sep 2000 18:31:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JMUbb30336; Tue, 19 Sep 2000 18:30:37 -0400 (EDT) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JMUIb12736 for ; Tue, 19 Sep 2000 18:30:23 -0400 (EDT) Received: from kitab.cisco.com (kitab.cisco.com [171.69.187.233]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id PAA00928 for ; Tue, 19 Sep 2000 15:30:00 -0700 (PDT) Received: (from raj@localhost) by kitab.cisco.com (8.9.3/8.9.2) id PAA01899; Tue, 19 Sep 2000 15:30:32 -0700 (PDT) (envelope-from raj) From: Richard Johnson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14791.59656.53565.277312@kitab.cisco.com> Date: Tue, 19 Sep 2000 15:30:32 -0700 (PDT) To: DHCPv6 discussion list Subject: Re: Q on DHCPv6 draft (draft-ietf-dhc-dhcpv6-15.txt) In-Reply-To: References: X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Indrajanti Sukiman writes: > My question is, what is the definition of 'a not valid link-local address'? > Or, in other words, how would agents perform this verification ? > As far as I can tell, RFC2462 defines an invalid link-local address as an > address whose valid lifetime has expired. If this is the definition > intended, is there a way e.g. for a DHCPv6 server to know the valid > lifetime of the link-local address of a remote (several hops away) DHCPv6 > client ? I feel sure what's meant is the definition from rfc1884.txt: 2.4.8 Local-use IPv6 Unicast Addresses There are two types of local-use unicast addresses defined. These are Link-Local and Site-Local. The Link-Local is for use on a single link and the Site-Local is for use in a single site. Link-Local addresses have the following format: | 10 | | bits | n bits | 118-n bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ Link-Local addresses are designed to be used for addressing on a single link for purposes such as auto-address configuration, neighbor discovery, or when no routers are present. Routers MUST not forward any packets with link-local source addresses. From owner-dhcp-v6@bucknell.edu Tue Sep 19 18:34:15 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25824; Tue, 19 Sep 2000 18:34:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JMXJb06189; Tue, 19 Sep 2000 18:33:19 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JMXBb01852 for ; Tue, 19 Sep 2000 18:33:11 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e8JMWsu14996 for ; Wed, 20 Sep 2000 00:32:54 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id AAA04756 for ; Wed, 20 Sep 2000 00:32:53 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id AAA22797 for ; Wed, 20 Sep 2000 00:34:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200009192234.AAA22797@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: Re: Francis's INput at the Design Meeting In-reply-to: Your message of Mon, 18 Sep 2000 10:38:30 EDT. <63D30D6E10CFD11190A90000F805FE8602BEC16C@lespaul.process.com> Date: Wed, 20 Sep 2000 00:34:41 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: I'm for keeping the DHCPv6 name. => the name doesn't really matter but: - IMHO it is important to understand DHCPv6 is more the statefull version of IPv6 autoconfiguration than the IPv6 version of DHCP, ie. it is supposed to add management to the existing stateless autoconf, not to do things which are exotic (for IPv6) or already done by other tools (like some service discovery). - formally the name DHCPv6 is wrong because it will apply to routers too (in fact, DHCPv6 is more useful for routers than for hosts because stateless autoconf works only for hosts). This point should be made clear in the new draft. ND Daemon is a Neighbor Discovery daemon, I suspect. => yes, ND is the nick name of Neighbor Discovery. Prefix discovery and address autoconfiguration are two of the nine functions of ND. I think Jim feels that DHCPv6 (client side) is really part of the ND Daemon that handles all addressing issues (whether stateful or not). => the code managing the stateless autoconf must interoperate with the DHCPv6 client. An easy way to do this is to manage both in an user daemon. Regards Francis.Dupont@enst-bretagne.fr From owner-dhcp-v6@bucknell.edu Tue Sep 19 18:54:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26076; Tue, 19 Sep 2000 18:54:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JMpZb06865; Tue, 19 Sep 2000 18:51:35 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JMpPb05433 for ; Tue, 19 Sep 2000 18:51:25 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e8JMp9u26074 for ; Wed, 20 Sep 2000 00:51:10 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id AAA04891 for ; Wed, 20 Sep 2000 00:51:06 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id AAA22858 for ; Wed, 20 Sep 2000 00:52:54 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200009192252.AAA22858@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: Re: Francis's INput at the Design Meeting In-reply-to: Your message of Mon, 18 Sep 2000 14:41:52 EDT. <200009181841.OAA32274@rotala.raleigh.ibm.com> Date: Wed, 20 Sep 2000 00:52:53 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: > I want to state I am now thinking Francis's input at the meeting may > make sense. Maybe this should not even be called DHCP but Stateful > Address Configuration for IPv6 (SACv6). The above title wouldn't seem to be consistent with DHCP being used to send configuration parameters other than addresses (e.g., server addresses, time zone info, etc.). => but is this really the job of DHCPv6? As soon as a node gets some not too local addresses it can use any service discovery protocol. IMHO it is not a good idea to overload DHCPv6 with secondary config tasks, ie. DHCPv6 should only manage addresses, DNS and security (security because of IPsec usage of destination addresses for SAs, DNS because we have no good lightweight/zeroconf DNS tools today). Francis.Dupont@enst-bretagne.fr PS: a part of DHCPv6 complexity, for instance relays or reconfigure, has no meaning if DHCPv6 is used for service discovery or parameter distribution. I don't ask to split DHCPv6 in two protocols because in fact service discovery and parameter distribution protocols already exist, they just don't work well with off-link nodes without routable addresses. From owner-dhcp-v6@bucknell.edu Tue Sep 19 19:05:06 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26197; Tue, 19 Sep 2000 19:05:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JN4Ab20345; Tue, 19 Sep 2000 19:04:10 -0400 (EDT) Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JN43b25100 for ; Tue, 19 Sep 2000 19:04:04 -0400 (EDT) Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA20425 for ; Tue, 19 Sep 2000 16:03:47 -0700 (PDT) Date: Tue, 19 Sep 2000 16:03:46 -0700 (PDT) From: Indrajanti Sukiman To: DHCPv6 discussion list Subject: Re: Q on DHCPv6 draft (draft-ietf-dhc-dhcpv6-15.txt) In-Reply-To: <14791.59656.53565.277312@kitab.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN So, given this, I conclude that the check at the agents whether or not the link-local address is valid or not valid, would be as trivial as checking the prefix of the link-local address is the well-known FE80::0 prefix ? On Tue, 19 Sep 2000, Richard Johnson wrote: > Indrajanti Sukiman writes: > > My question is, what is the definition of 'a not valid link-local address'? > > Or, in other words, how would agents perform this verification ? > > As far as I can tell, RFC2462 defines an invalid link-local address as an > > address whose valid lifetime has expired. If this is the definition > > intended, is there a way e.g. for a DHCPv6 server to know the valid > > lifetime of the link-local address of a remote (several hops away) DHCPv6 > > client ? > > I feel sure what's meant is the definition from rfc1884.txt: > > 2.4.8 Local-use IPv6 Unicast Addresses > > There are two types of local-use unicast addresses defined. These > are Link-Local and Site-Local. The Link-Local is for use on a single > link and the Site-Local is for use in a single site. Link-Local > addresses have the following format: > > | 10 | > | bits | n bits | 118-n bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ > > Link-Local addresses are designed to be used for addressing on a > single link for purposes such as auto-address configuration, neighbor > discovery, or when no routers are present. > > Routers MUST not forward any packets with link-local source > addresses. > > -- Indrajanti Sukiman From owner-dhcp-v6@bucknell.edu Tue Sep 19 21:25:45 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27650; Tue, 19 Sep 2000 21:25:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8K1Jmb11283; Tue, 19 Sep 2000 21:19:48 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8K1Jab27413 for ; Tue, 19 Sep 2000 21:19:37 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (sjck-dial-gw5-126.cisco.com [10.19.238.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA05739 for ; Tue, 19 Sep 2000 21:19:19 -0400 (EDT) Message-Id: <4.3.1.2.20000919180320.00af8de0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 19 Sep 2000 18:12:03 -0700 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: Francis's INput at the Design Meeting In-Reply-To: <200009192234.AAA22797@givry.rennes.enst-bretagne.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 12:34 AM 9/20/00 +0200, Francis Dupont wrote: > In your previous mail you wrote: > > I'm for keeping the DHCPv6 name. > >=> the name doesn't really matter but: > - IMHO it is important to understand DHCPv6 is more the statefull version > of IPv6 autoconfiguration than the IPv6 version of DHCP, ie. it is > supposed to add management to the existing stateless autoconf, not > to do things which are exotic (for IPv6) or already done by other > tools (like some service discovery). Can you tell me what you mean by "the stateful version of IPv6 autoconfiguration"? How does that differ from what the -15 draft of DHCPv6 does? - Ralph From owner-dhcp-v6@bucknell.edu Tue Sep 19 21:26:28 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27677; Tue, 19 Sep 2000 21:26:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8K1K7b05818; Tue, 19 Sep 2000 21:20:07 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8K1Jdb18912 for ; Tue, 19 Sep 2000 21:19:39 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (sjck-dial-gw5-126.cisco.com [10.19.238.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA05755; Tue, 19 Sep 2000 21:19:22 -0400 (EDT) Message-Id: <4.3.1.2.20000919181224.00bd4e00@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 19 Sep 2000 18:14:18 -0700 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: Francis's INput at the Design Meeting In-Reply-To: <200009192252.AAA22858@givry.rennes.enst-bretagne.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 12:52 AM 9/20/00 +0200, Francis Dupont wrote: > In your previous mail you wrote: > > > I want to state I am now thinking Francis's input at the meeting may > > make sense. Maybe this should not even be called DHCP but Stateful > > Address Configuration for IPv6 (SACv6). > > The above title wouldn't seem to be consistent with DHCP being used to > send configuration parameters other than addresses (e.g., server > addresses, time zone info, etc.). > >=> but is this really the job of DHCPv6? As soon as a node gets some >not too local addresses it can use any service discovery protocol. >IMHO it is not a good idea to overload DHCPv6 with secondary config >tasks, ie. DHCPv6 should only manage addresses, DNS and security >(security because of IPsec usage of destination addresses for SAs, >DNS because we have no good lightweight/zeroconf DNS tools today). In theory, I agree with you. In practice, we've waited a *long* time for a discovery protocol in the current protocol suite. Do we have any confidence that we'll have a discovery protocol specified and deployed to take ove that role from DHCPv6? - Ralph From owner-dhcp-v6@bucknell.edu Tue Sep 19 21:43:51 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28942; Tue, 19 Sep 2000 21:43:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8K1dtb30848; Tue, 19 Sep 2000 21:39:55 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8K1dfb07166 for ; Tue, 19 Sep 2000 21:39:41 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (sjck-dial-gw5-126.cisco.com [10.19.238.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA07138 for ; Tue, 19 Sep 2000 21:39:17 -0400 (EDT) Message-Id: <4.3.1.2.20000919182913.00af6340@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 19 Sep 2000 18:32:41 -0700 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: DHCPv6 address model proposal... In-Reply-To: <200009191546.LAA0000539338@anw.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 11:46 AM 9/19/00 -0400, Jim Bound wrote: >It makes most sense for the > >renewal time to be less than the valid lifetimes of all of the IPv6 > >addresses in the IA. > >SHould be less than the preferred times. Agreed... > >In > >any event, the server is authoritative about the set of addresses and > >lifetimes in the IA. > >Have to watch for DOS attacks as in IPv6 Stateless where router sends >zero valid lifetimes with Router Advertisement. This DOS attack would come from a malicious server? >Also if a server does >not return an address which may have valid lifetime left and telnet >running the connection will be broken as a note. Yes. - Ralph From owner-dhcp-v6@bucknell.edu Wed Sep 20 12:45:05 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26992; Wed, 20 Sep 2000 12:45:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8KGfjb29365; Wed, 20 Sep 2000 12:41:45 -0400 (EDT) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8KGfYb13969 for ; Wed, 20 Sep 2000 12:41:34 -0400 (EDT) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id E018F2086; Wed, 20 Sep 2000 12:41:18 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id C52F0E99 for ; Wed, 20 Sep 2000 12:41:18 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id MAA0000537482; Wed, 20 Sep 2000 12:40:47 -0400 (EDT) From: Jim Bound Message-Id: <200009201640.MAA0000537482@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-reply-to: Your message of "Tue, 19 Sep 2000 18:32:41 PDT." <4.3.1.2.20000919182913.00af6340@mail.bucknell.edu> Date: Wed, 20 Sep 2000 12:40:47 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > >In > >any event, the server is authoritative about the set of addresses and > >lifetimes in the IA. > >Have to watch for DOS attacks as in IPv6 Stateless where router sends >zero valid lifetimes with Router Advertisement. >This DOS attack would come from a malicious server? I think thats the catch. But then again my reading of a lot of discussion is that the IETF community trusts servers more than say other nodes sending stuff in client server protocol like DHCP. I just mentioned it as heads up. Thomas you know this stuff pretty well from stateless addrconf can you comment for us? thanks (note all I did was implement what thomas specified in addrconf in this space about only 20 lines of new code). /jim From owner-dhcp-v6@bucknell.edu Wed Sep 20 13:18:42 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28082; Wed, 20 Sep 2000 13:18:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8KHFqb12737; Wed, 20 Sep 2000 13:15:52 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8KHFdb11716 for ; Wed, 20 Sep 2000 13:15:39 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e8KHF7u31987 for ; Wed, 20 Sep 2000 19:15:12 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA14854 for ; Wed, 20 Sep 2000 19:15:07 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA27083 for ; Wed, 20 Sep 2000 19:16:58 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200009201716.TAA27083@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: Re: Francis's INput at the Design Meeting In-reply-to: Your message of Tue, 19 Sep 2000 18:14:18 PDT. <4.3.1.2.20000919181224.00bd4e00@mail.bucknell.edu> Date: Wed, 20 Sep 2000 19:16:58 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: In theory, I agree with you. In practice, we've waited a *long* time for a discovery protocol in the current protocol suite. Do we have any confidence that we'll have a discovery protocol specified and deployed to take over that role from DHCPv6? => we should try to split on a paper the address management part of DHCPv6 and the general discovery part. I believe two different protocols won't be really larger than the current multi-purpose one, and if we look at current issues it is clear most of them belong to only one of the two parts. Again the situation of IPv4 is different, in IPv6 we already have a form of autoconfig then it is reasonable to use DHCPv6 only for the discovery part but in this case why to use relays, ... The real question is what is the faster way from today: throw away the discovery part in order to get the stateful autoconf ASAP (IPv6 way :-) or the recycle again and again the multi-purpose thing until we get something useable (DHC/current way :-). Regards Francis.Dupont@enst-bretagne.fr PS: I propose to start with a simple example, for instance NIS server discovery: if the NIS server is not on-link then we can assume the node has already a not-too-local address (or it won't be able to reach the NIS server) then the relay function should be garbage collected. The information is not releasable (:-) and can be got several time then a multicast request / unicast (multiple) reply works (remove solicit/ advertisement). The reconfigure function has no more critical too... This gives a far simpler protocol! From owner-dhcp-v6@bucknell.edu Wed Sep 20 13:40:28 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28733; Wed, 20 Sep 2000 13:40:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8KHdvb18375; Wed, 20 Sep 2000 13:39:57 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8KHdlb03618 for ; Wed, 20 Sep 2000 13:39:47 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e8KHdVu21477 for ; Wed, 20 Sep 2000 19:39:31 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA15123 for ; Wed, 20 Sep 2000 19:39:30 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA27181 for ; Wed, 20 Sep 2000 19:41:22 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200009201741.TAA27181@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: Re: Francis's INput at the Design Meeting In-reply-to: Your message of Tue, 19 Sep 2000 18:12:03 PDT. <4.3.1.2.20000919180320.00af8de0@mail.bucknell.edu> Date: Wed, 20 Sep 2000 19:41:22 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: Can you tell me what you mean by "the stateful version of IPv6 autoconfiguration"? => according to RFC 2461 introduction: (what is autoconfiguration) This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere. (what is the stateful autoconfiguration) In the stateful autoconfiguration model, hosts obtain interface addresses and/or configuration information and parameters from a server. Servers maintain a database that keeps track of which addresses have been assigned to which hosts. The stateful autoconfiguration protocol allows hosts to obtain addresses, other configuration information or both from a server. Stateless and stateful autoconfiguration complement each other. For example, a host can use stateless autoconfiguration to configure its own addresses, but use stateful autoconfiguration to obtain other information. Stateful autoconfiguration for IPv6 is the subject of future work [DHCPv6]. How does that differ from what the -15 draft of DHCPv6 does? => my concern is about the "other informations". Some are critical (security, DNS), some can be useful (NIS/NIS+/WINS server), some are only ridiculous (weather schedule :-). The current draft tries to be multi-purpose, IMHO this is a bad idea because this makes DHCPv6 even more complex and not suitable for a simple discovery mechanism. Perhaps it is not the time to discuss about this (even if this issue is a source of the incredible delay of DHCPv6) but I argue (and I'll continue to argue) that the priority is the address configuration. We already have the stateless autoconfiguration for years then: - we have the proof the discovery part is not (yet) critical - we have a lot of constraints on address configuration (ie. in some cases DHCPv6 should do the same thing than stateless autoconf with the "database that keeps track of which addresses have been assigned to which hosts" in (only) addition) Regards Francis.Dupont@enst-bretagne.fr From owner-dhcp-v6@bucknell.edu Wed Sep 20 20:44:16 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12158; Wed, 20 Sep 2000 20:44:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8L0f5b29245; Wed, 20 Sep 2000 20:41:05 -0400 (EDT) Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8L0epb29073 for ; Wed, 20 Sep 2000 20:40:52 -0400 (EDT) Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345) id 90D0F3DFA; Wed, 20 Sep 2000 19:40:36 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 27C80266E for ; Wed, 20 Sep 2000 19:40:36 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id UAA0000592906; Wed, 20 Sep 2000 20:40:04 -0400 (EDT) From: Jim Bound Message-Id: <200009210040.UAA0000592906@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 o n Conference Call Agenda) In-reply-to: Your message of "Mon, 18 Sep 2000 18:38:07 EDT." <63D30D6E10CFD11190A90000F805FE8602BEC178@lespaul.process.com> Date: Wed, 20 Sep 2000 20:40:03 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >You might also solve them by: >- Having the client remember the "transaction id" / server source address >and dropping any reconfigure messages with the same transaction id received >within some time period (several minutes?). Of course, all subsequent >retransmitted reconfigure messages MUST use the same "transaction id". >- Having the client ignore additional multicast reconfigure messages (on the >same interface) for some time period after receiving one (again, several >minutes). This method has the added benefit that fake messages can't >repeatedly trigger reconfigurations except at some reasonable slow rate. Of >coures, it makes multiple renumbering events take longer (but that they'd >occur within minutes of each other is rather unlikely anyway). Yes this would work. But I think the idea Ralph proposed by server does multicast once for trigger reconfigure-init and then unicast for those that did not respond is a simpler solution for now? A more complex solution later can be adapted or extended later from what Ralph proposed pretty easily. But I do think your idea has much merit. >I do think the technique in 12.4.2 is somewhat flawed anyway since if one or >more clients are down, the "expected" number of messages may never be >returned. That would need to be fixed I thought we put wording about this elsewhere but I will check, it might be we only did it for the reconfigure and not the reconfigure-reply. >I think a better server strategy is to multicast several Reconfigure >messages several seconds apart (this presumes that a client hopefully won't >miss all if it is up and on the network). Then, if any clients fail to >respond within the alloted time, those clients are sent unicast packets. >(Perhaps the server can also make a determination of how many clients failed >to response and if it exceeds some threshold (>50?), it MAY multicast again >with the same transaction-id). We did put threshold in there for reconfigure. But I agree this can work as you suggest. Also I think we have to assume one multicast message normally works or we are not really assuming multicast works. There should be no reason to send multiple multicast messages unless there is a network problem. I suppose if no one responds and then unicasting a few to see if it works would be a good way to implemement this (not saying put this in the spec). regards, /jim From owner-dhcp-v6@bucknell.edu Wed Sep 20 22:51:26 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15341; Wed, 20 Sep 2000 22:51:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8L2mTb08265; Wed, 20 Sep 2000 22:48:29 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8L2mRb08609 for ; Wed, 20 Sep 2000 22:48:27 -0400 (EDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA04521 for ; Wed, 20 Sep 2000 19:48:26 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id TAA06713 for ; Wed, 20 Sep 2000 19:48:26 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8L2mPa328538 for ; Wed, 20 Sep 2000 19:48:25 -0700 (PDT) Date: Wed, 20 Sep 2000 19:47:45 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Co nference Call Agenda) To: DHCPv6 discussion list In-Reply-To: "Your message with ID" <4.3.1.2.20000915092521.00b92590@mail.bucknell.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Catching up on email ... somebody else might have already brought this up. > I don't think multicast adds efficiency. It only reduces the number of > messages by a constant factor (1/2 at best) and makes reliable > communication with clients significantly more difficult. Security is also > a significant issue for multicast. I agree that it doesn't add efficiency. But in the case where the DHCP server isn't handing out addresses it might not retain knowledge of all the clients. Being able to use multicast in that case to tell all interested clients that there is an updated value to the foo option, while still requiring O(n) packets, might be useful. > We can always add multicast later... Agreed. Erik From owner-dhcp-v6@bucknell.edu Wed Sep 20 23:12:54 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15591; Wed, 20 Sep 2000 23:12:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8L3Cbb24983; Wed, 20 Sep 2000 23:12:37 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8L3CWb17203 for ; Wed, 20 Sep 2000 23:12:32 -0400 (EDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07956 for ; Wed, 20 Sep 2000 20:12:31 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id UAA09372 for ; Wed, 20 Sep 2000 20:12:31 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8L3CPa332877 for ; Wed, 20 Sep 2000 20:12:26 -0700 (PDT) Date: Wed, 20 Sep 2000 20:11:48 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Co nference Call Agenda) To: DHCPv6 discussion list In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph, > In any event, multicast is intuitively appealing. But the devil appears > to be in the details. I hope this summary is both concise and precise... The summary captures the case when the server knows the addresses of all the clients it wants to reconfigure. If the DHCP server doesn't hand out address to a set of clients it might not want to track the identity of those clients that have only received "random" DHCP options/extensions. But the server might still be interested in being able to use reconfigure to "update" those random options. Using multicast in that case has a different set of issues... Presumably the DHCP server wants to reach all clients so that they all get the new information (option content) and purge the old information. But the server doesn't know the whole set of clients that it needs to receive messages from. RFC 2894 has a theoretical approach to this type of problem in section 8 for those interested. But the high-level point is carried in the IESG note in that RFC: This document defines mechanisms for informing a set of routers of renumbering operations they are to perform, including a mode of operation in environments in which the exact number of routers is unknown. Reliably informing all routers when the actual number of routers is unknown is a difficult problem. Implementation and operational experience will be needed to fully understand the applicabilty and scalability aspects of the mechanisms defined in this document when the number of routers is unknown. So while it might be interesting to think about using multicast reconfigure in this "reconfigure non-address information" case, it is a very hard problem to do reliably. Erik From owner-dhcp-v6@bucknell.edu Wed Sep 20 23:37:53 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16253; Wed, 20 Sep 2000 23:37:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8L3ZTb26472; Wed, 20 Sep 2000 23:35:29 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8L3ZJb08612 for ; Wed, 20 Sep 2000 23:35:19 -0400 (EDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA11081 for ; Wed, 20 Sep 2000 20:35:18 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id UAA11845 for ; Wed, 20 Sep 2000 20:35:17 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8L3ZGa336908 for ; Wed, 20 Sep 2000 20:35:16 -0700 (PDT) Date: Wed, 20 Sep 2000 20:34:38 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DHCPv6 address model proposal... To: DHCPv6 discussion list In-Reply-To: "Your message with ID" <4.3.1.2.20000919062909.00ae96e0@mail.bucknell.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph, > Let me see if I can successfully summarize the address model we've been > discussing: > > [...] > > The renewal time defines the time at which the client must contact the > server to get the current state of the IA (call this "renewing" the > IA). The renewal time is independent of the address lifetimes of any of > the lifetimes of the IPv6 addresses in the IA. It makes most sense for the > renewal time to be less than the valid lifetimes of all of the IPv6 > addresses in the IA. I think the last sentence is actually too much of a simplification. First of all, for addresses that are fully in use ("preferred" in RFC 2462 terminology i.e. they are neither "deprecated" or "invalid") you'd really want the renewal time to be less than the shortest preferred lifetime. This is to ensure that an address doesn't "accidentally" become deprecated or invalid before the IA is renewed. Thus there has to be some fudge to allow for the DHCP message exchange necessary to renew the IA. But this is not a hard rule. For instance, I expect there will be cases when a preferred and/or valid lifetime for an address is forced to zero as part of a renewal. Clearly in this case the next renewal time should not be zero. > When the client renews an IA, the server tells the client about the current > set of IPv6 addresses in the IA. The server may change the set of > addresses or the lifetimes of existing addresses during this renewal. For > example, setting a longer lifetime on an address already in the IA is the > equivalent of extending the lease on a DHCPv4-managed address. Leaving an > address out of an IA marks it immediately as no longer valid for the > client. Adding a new address to the IA can be used for renumbering. In > any event, the server is authoritative about the set of addresses and > lifetimes in the IA. Hmm, it isn't obvious that we need another way to invalidate an address (by leaving it out from the IA). Isn't it sufficient to be explicit about invalidating an address by including it with a zero valid and preferred lifetime? Erik > - Ralph > > At 09:10 PM 9/15/00 -0700, you wrote: > > > > OK but why is that different than the valid lifetime? In IPv6 if the > > > valid timer goes off the connection gets broken. > > > >The identity association's renewal time is a construct, based on a > >process of aggregating all the preferred times (probably) for all the > >addresses in an identity association. It exists so that you don't > >have to renew addresses seperately, and secondarily so that you don't > >send pointless renewal messages for non-renewable addresses. > > > > > I just want to be sure we have not maybe solved this timer problem with > > > the valid lifetime for an address. > > > >I don't think so - the valid timer serves the purpose of making sure > >that an address stops being used once it becomes invalid, and the > >renewal timer causes renewal packets to be generated - two different, > >albeit related, purposes. > > > > > But then we could say the renewal time is for the address set in total? > > > >Precisamento! :') > > > > > I can live with the client sending back all addresses when it wants to > > > renew the global address and that will work with the existing IPv6 > > > Address Extension. It does add extra bytes to the message and I think > > > we need to at least acknowledge that to a mobile node until we see 156kb > > > pedestrian throughput for mobile roaming there is a point where we do > > > need to reduce the bytes we won't see those speeds as I read the Tea > > > Leaves for Wireless till 2003 as a note. > > > > > > I think it fair to ask the WG how they feel about this? > > > > > > Do we try to save bytes for mobile nodes in DHCPv6? I think we should > > > if its not too complex to implement which is the engineering trade-off. > > > >I think if you do the math it's not the clear cut, *particularly* for > >a mobile node. Let's say for simplicity (so we have to only talk > >about one identity association) that you have a mobile node that's not > >doing mobile IP - it's just changing its address from time to time as > >it moves around, and doing short-lived transactions on the network. > >And right now you're sitting in your office with it. Let's say you > >get a global address and a site-local address, and the server is > >giving the global address a renewal time of 24 hours, but the site- > >local address has a renewal time of a week. So if you renew > >addresses together, over a week period, you get this: > > > >T+0d00h: DHCPsolicit+DHCPadvertise+DHCPrequest+DHCPreply > >T+0d12h: DHCPrequest+DHCPreply > >T+1d00h: DHCPrequest+DHCPreply > >T+1d12h: DHCPrequest+DHCPreply > >T+2d00h: DHCPrequest+DHCPreply > >T+2d12h: DHCPrequest+DHCPreply > >T+3d00h: DHCPrequest+DHCPreply > >T+3d12h: DHCPrequest+DHCPreply > >T+4d00h: DHCPrequest+DHCPreply > >T+4d12h: DHCPrequest+DHCPreply > >T+5d00h: DHCPrequest+DHCPreply > >T+5d12h: DHCPrequest+DHCPreply > >T+6d00h: DHCPrequest+DHCPreply > >T+6d12h: DHCPrequest+DHCPreply > >T+7d00h: DHCPrequest+DHCPreply > > > >So you have 1 DHCPsolicit, 1 DHCPadvertise, 15 DHCPrequests and 15 > >DHCPreplies. So using the current IP Address extension, each > >DHCPreply contains 64 octets of address extensions, plus a minimal > >IPv6 header of what, maybe 40 octets, 8 octets of UDP header, and > >maybe 16 octets of framing, plus maybe another 64 octets of other > >extensions, plus a 16-octet signature, for a total of 208 octets. The > >DHCPrequests, I'm not so sure about, but I'm not convinced that it is > >going to be usual in a situation like this for them to contain > >explicit address requests, so let's say they're more like 64 octets of > >header, 16 octets of extensions and 16 octets of signature, for a > >total of 96 octets. The DHCPsolicit is probably roughly the same size > >as the DHCPrequest - 96 octets. The DHCPadvertise might be as large > >as the DHCPreply - 208 octets. So you have 16 208-octet packets and > >16 96-octet packets. So the total traffic size in this scenario is > >4864 bytes. > > > >Now consider your scenario - we have: > > > >T+0d00h: DHCPsolicit+DHCPadvertise+DHCPrequest+DHCPreply for both addresses > >T+0d12h: DHCPrequest+DHCPreply for global > >T+1d00h: DHCPrequest+DHCPreply for global > >T+1d12h: DHCPrequest+DHCPreply for global > >T+2d00h: DHCPrequest+DHCPreply for global > >T+2d12h: DHCPrequest+DHCPreply for global > >T+3d00h: DHCPrequest+DHCPreply for global > >T+3d12h: DHCPrequest+DHCPreply for global > >T+4d00h: DHCPrequest+DHCPreply for global > >T+4d12h: DHCPrequest+DHCPreply for global > >T+5d00h: DHCPrequest+DHCPreply for global > >T+5d12h: DHCPrequest+DHCPreply for global > >T+6d00h: DHCPrequest+DHCPreply for global > >T+6d12h: DHCPrequest+DHCPreply for global > >T+7d00h: DHCPrequest+DHCPreply for global and site-local > > > >So here you have one DHCPsolicit, one DHCPadvertise, 15 DHCPrequests > >and two DHCPreplies that are the same size as in the previous > >scenario, for 16x96+3x208. Plus, you have 13 DHCPreplies that are > >174 bytes, so this adds up to a total of 4422 bytes. > > > >So the actual difference in traffic here is 442 bytes - about 10%. > >And this is the *worst case scenario*, which you will almost never see > >in the context of a roaming device in the real world. It has a > >site-local and global address with very different lifetimes, which is > >unlikely in a mobile phone context in the first place. It didn't > >move around, so you didn't have to renew because of cell transitions. > >If we'd been renewing on cell transitions, there's a good chance we > >would have seen the same number of bytes in both cases, because the > >renewals would have happened before either lifetime expired. > > > >So I think in the real world, with a mobile device like a cell phone, > >you are going to see no difference in bandwidth consumption. > >Furthermore, the worst-case scenario I described is susceptible to > >compression, and we might well want to specify a compression mechanism > >for low-bandwidth mobile devices anyway. This would probably burn > >that 10% down to 1% - an "I didn't move" renewal is going to have a > >tiny payload in both directions. > > > >So I really think that the bandwidth argument isn't a good argument > >against this scheme. > > > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Sep 21 03:11:08 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00770; Thu, 21 Sep 2000 03:11:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8L78Qb03576; Thu, 21 Sep 2000 03:08:26 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8L78Fb07549 for ; Thu, 21 Sep 2000 03:08:15 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-242.ip.theriver.com [206.97.58.242]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA15474; Tue, 19 Sep 2000 20:32:46 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8L74t309418; Thu, 21 Sep 2000 00:04:59 -0700 (MST) Message-Id: <200009210704.e8L74t309418@grosse.bisbee.fugue.com> To: DHCPv6 discussion list cc: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Erik Nordmark of "Wed, 20 Sep 2000 20:34:38 MST." Date: Thu, 21 Sep 2000 00:04:55 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Hmm, it isn't obvious that we need another way to invalidate an address > (by leaving it out from the IA). Isn't it sufficient to be explicit about > invalidating an address by including it with a zero valid and preferred > lifetime? This requires the server to remember that the client had that address, so it's actually not a simplification - it makes additional work for the server, which now has to track the administrative removal of non-renewable addresses. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Sep 21 16:03:23 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13666; Thu, 21 Sep 2000 16:03:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8LJxtb04082; Thu, 21 Sep 2000 15:59:59 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8LJxcb09282 for ; Thu, 21 Sep 2000 15:59:38 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (rtp-dial-1-237.cisco.com [10.83.97.237]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA13218 for ; Thu, 21 Sep 2000 15:59:18 -0400 (EDT) Message-Id: <4.3.1.2.20000921153756.00ba2d10@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 21 Sep 2000 15:59:08 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: DHCPv6 address model proposal... In-Reply-To: References: <"Your message with ID" <4.3.1.2.20000919062909.00ae96e0@mail.bucknell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 08:34 PM 9/20/00 -0700, Erik Nordmark wrote: >Hmm, it isn't obvious that we need another way to invalidate an address >(by leaving it out from the IA). Isn't it sufficient to be explicit about >invalidating an address by including it with a zero valid and preferred >lifetime? My thought was that specifying that the server send a complete list of only the client's currently valid addresses was actually a simplification - the client can simply throw out its old list of addresses and copy down the current list from the server. However, there is a second step - the client has to update the configuration of its interfaces with the list of addresses from the server. So, I imagine simply omitting addresses makes the client's job a little harder - it has to poke around at each of the interfaces and see if any of the addresses on those interfaces were missing from the message and must therefore be un-configured. But, as Ted points out, requiring the server to specifically invalidate addresses may make the server implementation more complex - the server will have to remember each client's previous list of assigned addresses as well as any newly assigned addresses until the client has renewed its IA. - Ralph From owner-dhcp-v6@bucknell.edu Thu Sep 21 16:04:17 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13750; Thu, 21 Sep 2000 16:04:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8LK1qb04132; Thu, 21 Sep 2000 16:01:53 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8LK1eb01829 for ; Thu, 21 Sep 2000 16:01:41 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (rtp-dial-1-237.cisco.com [10.83.97.237]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA13529 for ; Thu, 21 Sep 2000 16:01:21 -0400 (EDT) Message-Id: <4.3.1.2.20000921155922.00ba2500@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 21 Sep 2000 16:03:32 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: DHCPv6 address model proposal... In-Reply-To: References: <"Your message with ID" <4.3.1.2.20000919062909.00ae96e0@mail.bucknell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 08:34 PM 9/20/00 -0700, Erik Nordmark wrote: > > It makes most sense for the > > renewal time to be less than the valid lifetimes of all of the IPv6 > > addresses in the IA. > >I think the last sentence is actually too much of a simplification. >First of all, for addresses that are fully in use ("preferred" in RFC 2462 >terminology i.e. they are neither "deprecated" or "invalid") >you'd really want the renewal time to be less than the shortest preferred >lifetime. Yes, making the renewal time shorter than the shortest preferred lifetime would likely be more desirable in most cases. Without getting overly complex or prescriptive, perhaps the text in the spec could say that the renewal time MUST be "less than the valid lifetimes of all of the IPv6 addresses in the IA" for correctness and MAY be "less than the shortest preferred lifetime" to be more conservative. - Ralph From owner-dhcp-v6@bucknell.edu Thu Sep 21 16:22:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13931; Thu, 21 Sep 2000 16:22:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8LKMUb28813; Thu, 21 Sep 2000 16:22:30 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8LKMHb02533 for ; Thu, 21 Sep 2000 16:22:17 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a17.pm3-32.theriver.com [206.102.192.81]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id JAA19071 for ; Wed, 20 Sep 2000 09:46:48 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8LKIPb03081 for ; Thu, 21 Sep 2000 13:18:34 -0700 (MST) Message-Id: <200009212018.e8LKIPb03081@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Ralph Droms of "Thu, 21 Sep 2000 15:59:08 -0400." <4.3.1.2.20000921153756.00ba2d10@mail.bucknell.edu> Date: Thu, 21 Sep 2000 13:18:25 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > So, I imagine simply omitting addresses makes the client's job a > little harder - it has to poke around at each of the interfaces and see if > any of the addresses on those interfaces were missing from the message and > must therefore be un-configured. I doubt a client would poke the interfaces to see what addresses they have; rather, it would probably remember what addresses were in its address association. I think it needs to do this either way. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Sep 21 16:26:50 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14010; Thu, 21 Sep 2000 16:26:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8LKQWb14596; Thu, 21 Sep 2000 16:26:32 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8LKQNb19004 for ; Thu, 21 Sep 2000 16:26:24 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a17.pm3-32.theriver.com [206.102.192.81]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id JAA19083 for ; Wed, 20 Sep 2000 09:50:55 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8LKMeb03144 for ; Thu, 21 Sep 2000 13:22:40 -0700 (MST) Message-Id: <200009212022.e8LKMeb03144@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Ralph Droms of "Thu, 21 Sep 2000 16:03:32 -0400." <4.3.1.2.20000921155922.00ba2500@mail.bucknell.edu> Date: Thu, 21 Sep 2000 13:22:40 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Yes, making the renewal time shorter than the shortest preferred lifetime > would likely be more desirable in most cases. Without getting overly > complex or prescriptive, perhaps the text in the spec could say that the > renewal time MUST be "less than the valid lifetimes of all of the IPv6 > addresses in the IA" for correctness and MAY be "less than the shortest > preferred lifetime" to be more conservative. I think the failover protocol takes advantage of the 50% renewal time to provide consistent lease times, so it may be good to specify that the renewal time should be something like half the duration of the valid lifetime, or 80% of the preferred lifetime, whichever is shorter. I'd prefer to just say half the valid lifetime, but it's possible that the valid lifetime could be more than twice as long as the preferred lifetime. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Sep 21 17:02:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14397; Thu, 21 Sep 2000 17:02:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8LKxib16892; Thu, 21 Sep 2000 16:59:44 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8LKxSb19521 for ; Thu, 21 Sep 2000 16:59:28 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (rtp-dial-1-196.cisco.com [10.83.97.196]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA21714 for ; Thu, 21 Sep 2000 16:59:11 -0400 (EDT) Message-Id: <4.3.1.2.20000921165538.00ba37e0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 21 Sep 2000 17:01:16 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: DHCPv6 address model proposal... In-Reply-To: <200009212018.e8LKIPb03081@grosse.bisbee.fugue.com> References: <4.3.1.2.20000921153756.00ba2d10@mail.bucknell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 01:18 PM 9/21/00 -0700, you wrote: > > So, I imagine simply omitting addresses makes the client's job a > > little harder - it has to poke around at each of the interfaces and see if > > any of the addresses on those interfaces were missing from the message and > > must therefore be un-configured. > >I doubt a client would poke the interfaces to see what addresses they >have; rather, it would probably remember what addresses were in its >address association. I think it needs to do this either way. Right. That's what I get for trying to guess about implementation strategies... In any event, if I've got it right, we can assume the client can do the right thing to change its address configuration to match the configuration from the server, and the server need not take responsibility for remembering the client's previous configuration. - Ralph From owner-dhcp-v6@bucknell.edu Thu Sep 21 20:53:09 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16515; Thu, 21 Sep 2000 20:53:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8M0odb21721; Thu, 21 Sep 2000 20:50:39 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8M0oMb31198 for ; Thu, 21 Sep 2000 20:50:23 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Sep 2000 20:50:07 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC189@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Co nference Call Agenda) Date: Thu, 21 Sep 2000 20:50:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >> We can always add multicast later... > >Agreed. > > Erik I'm not sure I agree with this. But, it all depends on what you mean by later. If you're saying not in this revision of the draft, OK. If you're saying 3 years from now, I think that would be a bad and wrong assumption. You'll have deployed clients (at least I'm assuming "this time" IPv6 will be deployed relatively soon - 3 to 4 years ago we were assuming that). Changing those clients won't come easy because you're assuming we can revise the spec and they'll all start working - ha! If no clients support multicast reconfigure, what reason is there for servers to implement it or use it? If no servers implement or use it, why build clients that will? Perhaps I'm being too alarmist here, but I see this as a fairly fundamental issue and it should be resolved now. I have NO problem in saying that "clients MUST ignore multicast reconfigure messages unless those message are authenticated in some manner that is still TBD (perhaps via IPsec, a server authenticator, or some other means)." This is again somewhat of an issue since clients will not use these packets until the authentication method is specified. - Bernie Volz From owner-dhcp-v6@bucknell.edu Thu Sep 21 20:57:10 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16558; Thu, 21 Sep 2000 20:57:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8M0upb15765; Thu, 21 Sep 2000 20:56:51 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8M0uhb03255 for ; Thu, 21 Sep 2000 20:56:43 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Sep 2000 20:56:28 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC18A@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: renewal time Date: Thu, 21 Sep 2000 20:56:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I think this also means that there is no reason for the client to send the server the list of addresses it thinks are in the IA. Why waste the bits on the wire and the server processing time when the server will tell the client "here's the addresses associated with this IA" in the response anyway. I've not been following all the discussions to closely the past few days, so perhaps this was already considered. - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: Tuesday, September 19, 2000 9:08 AM To: DHCPv6 discussion list Subject: Re: renewal time I've been thinking of the action associated with renewal as the client asking the server "Tell me what addresses are in this IA now and how long I can use them". If the preferred/valid times have changed, it's like a lease extension. If a renumbering event is in progress, the server can assign new addresses. In any event, the server - based on all the information the server has about the client - is informing the client of the addresses currently in the IA - Ralph At 10:42 PM 9/18/00 -0700, Ted Lemon wrote: > > Correct new lease-times or the Server could not give the client an > > address back meaning its expired too. But no new addresses. > >Well, but if we're renumbering, the server might well give back a "new >address", right? I think the point is that that client isn't asking >the server to do this - it's asking the server to renew. From owner-dhcp-v6@bucknell.edu Thu Sep 21 21:01:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16610; Thu, 21 Sep 2000 21:01:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8M110b16397; Thu, 21 Sep 2000 21:01:00 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8M10pb05311 for ; Thu, 21 Sep 2000 21:00:51 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Sep 2000 21:00:32 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC18B@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: renewal time Date: Thu, 21 Sep 2000 21:00:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Why not new addresses? If a previous address expired or a reconfigure event is in progress, why can't there be a new address associated with the IA? - Bernie Volz -----Original Message----- From: Jim Bound [mailto:bound@zk3.dec.com] Sent: Monday, September 18, 2000 9:14 PM To: DHCPv6 discussion list Subject: Re: renewal time >Jim - when you say "when the client will REQUEST new addresses", do you >really mean _new_ addresses, as in _additional_ addresses? I think you mean >something like "will REQUEST that the server extend the lease-times >associated with a client-id": is that correct, or do you really mean "new >addresses"? Correct new lease-times or the Server could not give the client an address back meaning its expired too. But no new addresses. regards, /jim From owner-dhcp-v6@bucknell.edu Thu Sep 21 21:38:33 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17812; Thu, 21 Sep 2000 21:38:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8M1aDb12877; Thu, 21 Sep 2000 21:36:13 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8M1a5b06129 for ; Thu, 21 Sep 2000 21:36:06 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a17.pm3-32.theriver.com [206.102.192.81]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id PAA19954 for ; Wed, 20 Sep 2000 15:00:37 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8M1Vxb18446 for ; Thu, 21 Sep 2000 18:32:01 -0700 (MST) Message-Id: <200009220132.e8M1Vxb18446@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: renewal time In-Reply-To: Message from Bernie Volz of "Thu, 21 Sep 2000 21:00:30 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC18B@lespaul.process.com> Date: Thu, 21 Sep 2000 18:31:59 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Why not new addresses? If a previous address expired or a reconfigure event > is in progress, why can't there be a new address associated with the IA? You are right. I missed Jim's message about this, I guess. During a reconfigure event, the DHCP server can most definitely be expected to send the client an entirely new IP address for a particular address association. Without this, I don't see how the protocol can work. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Sep 21 21:38:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17833; Thu, 21 Sep 2000 21:38:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8M1cLb26982; Thu, 21 Sep 2000 21:38:21 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8M1c7b18354 for ; Thu, 21 Sep 2000 21:38:07 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a17.pm3-32.theriver.com [206.102.192.81]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id PAA19960 for ; Wed, 20 Sep 2000 15:02:38 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8M1Y2b18476 for ; Thu, 21 Sep 2000 18:34:02 -0700 (MST) Message-Id: <200009220134.e8M1Y2b18476@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: renewal time In-Reply-To: Message from Bernie Volz of "Thu, 21 Sep 2000 20:56:27 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC18A@lespaul.process.com> Date: Thu, 21 Sep 2000 18:34:02 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I think this also means that there is no reason for the client to send the > server the list of addresses it thinks are in the IA. Why waste the bits on > the wire and the server processing time when the server will tell the client > "here's the addresses associated with this IA" in the response anyway. There is a reason: to preserve address stability. But it's not a very good reason, and I think that by default the client probably shouldn't bother to tell the DHCP server what its old address was. There's only one catch here: we have to be careful that the client doesn't get its IA whacked around by two non-cooperating DHCP servers on the same wire. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Sep 21 22:11:46 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18038; Thu, 21 Sep 2000 22:11:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8M29Db26291; Thu, 21 Sep 2000 22:09:13 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8M292b17749 for ; Thu, 21 Sep 2000 22:09:02 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Sep 2000 22:08:46 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC18C@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: renewal time Date: Thu, 21 Sep 2000 22:08:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted: The multiple server case is an interesting one to consider. I would assume that the renewals and the like will go to the SAME server and therefore the client's IA is really specific to that server. But, this does create an interesting issue for renewals that are multicast (I'm lazy at the moment and don't recall the exact "renewal" steps in DHCPv6, but I assume we're allowing multicast at some time if the original server isn't responding). And, also for any failover protocol (since the servers are different, though they are cooperating). The failover "lazy update" approach may fail since if the partner server gets a renewal before the original server updated it with information, how will the partner know what addresses to give? Urgh! This really does mean there is a reason for the client to send the list of addresses on a renewal. This would give "other" servers a hint as to what the client had and the server can determine "oh, those look like reasonable addresses to me since they aren't in use (or in use by that client)". Note also that even if the renewal is sent to the same server, it is always possible that that server lost stable storage and thus there would be no information on the server and it would assign new addresses (perhaps not the same ones) unless the client also sent the addresses with the renewal. So ... scrap my thought of saving bits and processing. - Bernie Volz IPWorks, Inc. -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Thursday, September 21, 2000 9:34 PM To: DHCPv6 discussion list Subject: Re: renewal time > I think this also means that there is no reason for the client to send the > server the list of addresses it thinks are in the IA. Why waste the bits on > the wire and the server processing time when the server will tell the client > "here's the addresses associated with this IA" in the response anyway. There is a reason: to preserve address stability. But it's not a very good reason, and I think that by default the client probably shouldn't bother to tell the DHCP server what its old address was. There's only one catch here: we have to be careful that the client doesn't get its IA whacked around by two non-cooperating DHCP servers on the same wire. _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Sep 22 08:10:44 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11268; Fri, 22 Sep 2000 08:10:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8MC8Ab09229; Fri, 22 Sep 2000 08:08:10 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8MC82b31023 for ; Fri, 22 Sep 2000 08:08:02 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id IAA01083 for ; Fri, 22 Sep 2000 08:07:35 -0400 Message-Id: <200009221207.IAA01083@hygro.adsl.duke.edu> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Ted Lemon of "Fri, 15 Sep 2000 11:22:50 PDT." <200009151822.e8FIMoH01306@grosse.bisbee.fugue.com> Date: Fri, 22 Sep 2000 08:07:35 -0400 From: Thomas Narten Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted, Sorry to be so long in following up, but it sounds like we're basically in sync, except that terminology threw things off. Cool. One thing in your posting though has me thinking. > > In the mobile IP scenario, you will likely have *two* global > > addresses. One for your home address, and a temporary care of > > address. Both will need to be global in order for arbitrary sites to > > send packets to them. Note, however, that in this case the client will > > be interacting with two different DHCP servers in two different > > contexts. The care-of address comes from the local site that is being > > visited, the home address comes from the home site. So it's not clear > > you need to identity associations separately here (though you might > > want to), since two servers are involved and that is enough to > > distinguish which addresses one is talking about (i.e., care-of > > vs. home). > Right. So you have two identity associations. Then later: > > I hope not. If a client moves to a new link/subnet, it should just > > request that the DHCP server "give me the set of addresses that I'm > > supposed to have on the new link I just joined". > This sounds like the client is making a different request depending on > it's perception of the status of the link. Is there any particular > reason why the client can't just say "please renew this IA" and have > the server say "okay, because you're on a new link, here are your new > addresses?" I.e., the client asks the same question, rather than > having to be clever and decide which question to ask? The client > might be stimulated to ask for an early renewal because it noticed > that the router advertisements it was seeing had changed, but I don't > think it needs to explicitly tell the server "hey, I'm on a new > subnet." My assumption has been that when a node moves to a new link, it would ask for addresses using the *same* IA. I.e., the client doesn't want to know that it is on a new link and therefore needs to use a different IA when asking for new addresses (but that might be in conflict with your first point above). However, thinking about it, a mobile client *will* need to know its on a new link, as all sorts of things change for it if it moves to a new link (i.e, it needs a new first-hop router). So having it send a different IA when moving probably probably isn't a big deal either. But is it really necessary or desirable? Thoughts? Thomas From owner-dhcp-v6@bucknell.edu Fri Sep 22 08:17:36 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11423; Fri, 22 Sep 2000 08:17:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8MCHHb02957; Fri, 22 Sep 2000 08:17:17 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8MCH8b00676 for ; Fri, 22 Sep 2000 08:17:08 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id IAA01117 for ; Fri, 22 Sep 2000 08:16:42 -0400 Message-Id: <200009221216.IAA01117@hygro.adsl.duke.edu> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Ralph Droms of "Tue, 19 Sep 2000 06:39:34 PDT." <4.3.1.2.20000919062909.00ae96e0@mail.bucknell.edu> Date: Fri, 22 Sep 2000 08:16:42 -0400 From: Thomas Narten Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph, > When the client renews an IA, the server tells the client about the current > set of IPv6 addresses in the IA. The server may change the set of > addresses or the lifetimes of existing addresses during this renewal. For > example, setting a longer lifetime on an address already in the IA is the > equivalent of extending the lease on a DHCPv4-managed address. Leaving an > address out of an IA marks it immediately as no longer valid for the > client. Adding a new address to the IA can be used for renumbering. In > any event, the server is authoritative about the set of addresses and > lifetimes in the IA. I think that the only way to force a client to "invalidate" or "stop using" an address is to explicitely tell it that it now has a zero valid lifetime. Or, one can be silent (omit an address), but that *does* *not* invalidate the address and cause the client to stop using it per se. Rather, the client stops using an address when the addresses' valid lifetime goes to zero. This happens when it times out through normal expiration (only), but that can be hastened by having the server send an update saying "the lifetime has now become 0 (or some other small value)". My comparison point is stateless addrconf. One doesn't conclude an address is no longer valid because routers stop advertising it, one stops using an address when its lifetime expires. If an address is omitted from an RA, the client probably doesn't even notice this and doesn't do anything special. This would seem to simplify a lot of things. Note also, that a DHCP server probably *does* want to include all addresses, including those that will become invalid *very* soon, because other nodes may be trying to send traffic to those addresses. If a client has just restarted, it probably won't remember that it was using an address in the past, but you want it to configure all of its addresses. If it doesn't, you could run into an odd situation where a node might have an address (which could be in a deprecated state), the client reboots, but after reboot, it no longer has that address configured. But if it hadn't rebooted, it would. This would seem to be an undesirable situation. And again, it causes no problem for a client to assign a valid, but deprecated address to its interfaces. It won't use that address for new communication it *initiates*, but it will still accept traffic sent to that. This might happen if the deprecated address was still in the DNS. Thomas From owner-dhcp-v6@bucknell.edu Fri Sep 22 13:46:40 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21623; Fri, 22 Sep 2000 13:46:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8MHhtb05788; Fri, 22 Sep 2000 13:43:55 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8MHhmb28583 for ; Fri, 22 Sep 2000 13:43:48 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-229.ip.theriver.com [206.97.58.229]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id HAA23626 for ; Thu, 21 Sep 2000 07:08:19 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8MHcPw00582 for ; Fri, 22 Sep 2000 10:38:30 -0700 (MST) Message-Id: <200009221738.e8MHcPw00582@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Thomas Narten of "Fri, 22 Sep 2000 08:07:35 -0400." <200009221207.IAA01083@hygro.adsl.duke.edu> Date: Fri, 22 Sep 2000 10:38:25 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > However, thinking about it, a mobile client *will* need to know its > on a new link, as all sorts of things change for it if it moves to a > new link (i.e, it needs a new first-hop router). So having it send a > different IA when moving probably probably isn't a big deal > either. But is it really necessary or desirable? Yes, the highly-mobile client has to notice the link transition. No, it doesn't need to use a different IA on each link - indeed, it should not. The IA that notices link state changes is for its care-of address. The second IA is for its home address, if it's using DHCP to allocate that. _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Sep 22 13:48:24 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21677; Fri, 22 Sep 2000 13:48:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8MHm6b05413; Fri, 22 Sep 2000 13:48:06 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8MHlwb00241 for ; Fri, 22 Sep 2000 13:47:58 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-229.ip.theriver.com [206.97.58.229]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id HAA23656 for ; Thu, 21 Sep 2000 07:12:29 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8MHhOw00654 for ; Fri, 22 Sep 2000 10:43:24 -0700 (MST) Message-Id: <200009221743.e8MHhOw00654@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Thomas Narten of "Fri, 22 Sep 2000 08:16:42 -0400." <200009221216.IAA01117@hygro.adsl.duke.edu> Date: Fri, 22 Sep 2000 10:43:24 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Or, one can be silent (omit an address), but that *does* *not* > invalidate the address and cause the client to stop using it per > se. Rather, the client stops using an address when the addresses' > valid lifetime goes to zero. The way we have talked about this, the client remembers all its addresses, and the absence of one of these addresses in the response for an IA indicates that the client should stop using the address immediately. We can change to your semantics, but I'm not sure I see why this would be valuable - in particular, it seems to complicate things, not make them simpler. Can you be more explicit in saying why this is a simplification? The similarity to stateless addrconf is a simplification from a protocol perspective, but I'm talking about implementation here. > Note also, that a DHCP server probably *does* want to include all > addresses, including those that will become invalid *very* soon, > because other nodes may be trying to send traffic to those > addresses. If a client has just restarted, it probably won't remember > that it was using an address in the past, but you want it to configure > all of its addresses. I think the way we talked about doing this solves this problem - the client will never receive a DHCPreply that does not list all the valid addresses for a particular IA. The absence of an address in the DHCPreply means that it is no longer valid. So a client that's restarted _will_ get all its addresses. > If it doesn't, you could run into an odd situation where a node > might have an address (which could be in a deprecated state), the > client reboots, but after reboot, it no longer has that address > configured. So this can't happen. _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Sep 22 15:58:47 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25733; Fri, 22 Sep 2000 15:58:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8MJuAb10305; Fri, 22 Sep 2000 15:56:10 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8MJtwb30837 for ; Fri, 22 Sep 2000 15:55:58 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA09482 for ; Fri, 22 Sep 2000 15:55:42 -0400 (EDT) Message-Id: <4.3.1.2.20000922154355.00ba1220@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 22 Sep 2000 15:57:55 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: DHCPv6 address model proposal... In-Reply-To: <200009221216.IAA01117@hygro.adsl.duke.edu> References: <4.3.1.2.20000919062909.00ae96e0@mail.bucknell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 08:16 AM 9/22/00 -0400, Thomas Narten wrote: >I think that the only way to force a client to "invalidate" or "stop >using" an address is to explicitely tell it that it now has a zero >valid lifetime. Or, one can be silent (omit an address), but that >*does* *not* invalidate the address and cause the client to stop using >it per se. Rather, the client stops using an address when the >addresses' valid lifetime goes to zero. Can't we define explicitly define those semantics within DHCP? That is, can't we define a model in which the client and server agree that the server will send exactly the current state of the IA - the current list of addresses associated with the IA. With such a model, the server would resend every address that continues to be in the IA and drops those that are no longer in the IA. >>My comparison point is stateless addrconf. One doesn't >>conclude an address is no longer valid because routers >>stop advertising it, one stops using an address when >>its lifetime expires. I can understand the desire to be compatible with stateless autoconf. But DHCP allows for host-specific configuration information, rather than information multicast to many hosts. So the problem space is a little different, I think. I don't see where omitting some of the addresses sent from a host to a client simplifies anything - that list of addresses is just the current state for the client - while explicitly invalidating some addresses complicates the server logic by requiring that the server keep track of the client's previous state. In fact, specifically invalidating addresses complicates the protocol logic because, as Kim Kinnear pointed out to me earlier today, DHCP really manages a database of configuration information that's distributed among the server and the clients. If the server must explicitly invalidate client addresses, it must know what those addresses are. Easy enough, if the client and server are in sync. But, to guarantee correctness in the case that the client and server are out of sync, the server must know reliably what addresses the client has in the IA (the server can't assume that it's version of the IA is the same as the client's). So, that synchronization could be accomplished by requiring that the client send its version of the IA to the server, and the server could send back the changes - changing the lifetimes on some addresses, explicitly invalidating some addresses and adding new addresses. That seems more complicated to me than the server simply sending the client the current, correct, complete IA. >Note also, that a DHCP server probably *does* want to include all >addresses, including those that will become invalid *very* soon, >because other nodes may be trying to send traffic to those >addresses. Agreed... - Ralph From owner-dhcp-v6@bucknell.edu Fri Sep 22 16:04:41 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25811; Fri, 22 Sep 2000 16:04:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8MK4Jb14077; Fri, 22 Sep 2000 16:04:19 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8MK43b13291 for ; Fri, 22 Sep 2000 16:04:03 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA10568 for ; Fri, 22 Sep 2000 16:03:48 -0400 (EDT) Message-Id: <4.3.1.2.20000922155936.00ae8710@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 22 Sep 2000 16:06:00 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Co nference Call Agenda) In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEC189@lespaul.process.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 08:50 PM 9/21/00 -0400, you wrote: > >> We can always add multicast later... > > > >Agreed. > > > > Erik > >I'm not sure I agree with this. But, it all depends on what you mean by >later. I'm of two minds about "later" - on the one hand, I recognize that, based on our experience with DHCPv4, we need to get words in the spec now if we're ever going to deploy multicast reconfigure; on the other hand, we're already perilously close to slipping the 9/30 pub date for the next rev of the draft. - Ralph From owner-dhcp-v6@bucknell.edu Fri Sep 22 23:49:17 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04979; Fri, 22 Sep 2000 23:49:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8N3jPb07052; Fri, 22 Sep 2000 23:45:25 -0400 (EDT) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8N3jKb10829 for ; Fri, 22 Sep 2000 23:45:20 -0400 (EDT) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id 8B41C2287; Fri, 22 Sep 2000 22:45:04 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 19A7520E1 for ; Fri, 22 Sep 2000 22:45:04 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id XAA0000836629; Fri, 22 Sep 2000 23:44:45 -0400 (EDT) From: Jim Bound Message-Id: <200009230344.XAA0000836629@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: bound@ZK3.DEC.COM Subject: Re: DHCPv6 address model proposal... In-reply-to: Your message of "Fri, 22 Sep 2000 15:57:55 EDT." <4.3.1.2.20000922154355.00ba1220@mail.bucknell.edu> Date: Fri, 22 Sep 2000 23:44:44 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph, The current dhcpv6 does try to emulate what the router does in stateless addrconf but with the obvious need to support as you say all the knowledge the server must now keep by definition which the router does not try to in neighbor discovery. The router of course is truly stateless. The complexity to do this is to mirror the addrconf paradigm as close as possible. Thus a paradigm shift from DHCPv4. regards, /jim From owner-dhcp-v6@bucknell.edu Sat Sep 23 00:33:13 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05401; Sat, 23 Sep 2000 00:33:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8N4TYb27677; Sat, 23 Sep 2000 00:29:34 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8N4TRb26595 for ; Sat, 23 Sep 2000 00:29:27 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-229.ip.theriver.com [206.97.58.229]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id RAA25294; Thu, 21 Sep 2000 17:53:56 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8N4O4w11550; Fri, 22 Sep 2000 21:24:05 -0700 (MST) Message-Id: <200009230424.e8N4O4w11550@grosse.bisbee.fugue.com> To: DHCPv6 discussion list cc: bound@ZK3.DEC.COM Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Jim Bound of "Fri, 22 Sep 2000 23:44:44 -0400." <200009230344.XAA0000836629@anw.zk3.dec.com> Date: Fri, 22 Sep 2000 21:24:04 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > The complexity to do this is to mirror the addrconf paradigm > as close as possible. Thus a paradigm shift from DHCPv4. Mirroring the behaviour of one system designed for one purpose in another system designed for a different purpose is not a paradigm shift. It is just a design decision that you maked based on a cost/benefit analysis. We've talked about the issues involved quite a bit, although not from this particular perspective. I don't think trying to artificially impose similarities between stateless and stateful autoconfig is a good idea. _MelloN_ From owner-dhcp-v6@bucknell.edu Sat Sep 23 01:08:05 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06064; Sat, 23 Sep 2000 01:08:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8N546b02712; Sat, 23 Sep 2000 01:04:06 -0400 (EDT) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8N53sb14767 for ; Sat, 23 Sep 2000 01:03:54 -0400 (EDT) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id D4B748C5; Sat, 23 Sep 2000 01:03:38 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 2368C2987; Sat, 23 Sep 2000 01:03:38 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id BAA0000843899; Sat, 23 Sep 2000 01:02:48 -0400 (EDT) From: Jim Bound Message-Id: <200009230502.BAA0000843899@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: dhcp-v6@bucknell.edu, bound@ZK3.DEC.COM, bound@ZK3.DEC.COM Subject: Re: DHCPv6 address model proposal... In-reply-to: Your message of "Fri, 22 Sep 2000 21:24:04 PDT." <200009230424.e8N4O4w11550@grosse.bisbee.fugue.com> Date: Sat, 23 Sep 2000 01:02:43 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >> The complexity to do this is to mirror the addrconf paradigm >> as close as possible. Thus a paradigm shift from DHCPv4. >Mirroring the behaviour of one system designed for one purpose in >another system designed for a different purpose is not a paradigm >shift. It is just a design decision that you maked based on a >cost/benefit analysis. We've talked about the issues involved quite a >bit, although not from this particular perspective. I don't think >trying to artificially impose similarities between stateless and >stateful autoconfig is a good idea. The end result if implemented would be a paradigm shift completely. It is what would happen after the design decision was executed. Also it was not artificial but real by using the parts in IPv6 that made it possible. But, regardless we don't agree on your last point and I did not send this to debate it but rather as additional data for the conversation of stateful vs stateless. Also as I listen to Francis's input we should have taken the design a step further and did a stateful discovery protocol, then stateful address protocol, and then one for config parameters that are not addresses. And completely left the entire DHCP paradigm maybe. But what we have to do now is I think just permit the server to not return the address. But if the client still has time left to use that address the connection should not be broken as I believe that stateless addrconf as a spec is the architecture for that decision not ours. So if a server wants to stop a client from using an address that still has time left they should have to send the address back to the client with a reduced lease to end the connection and use of that address. Or just let it time out and it will not get it back and in this new model it can't request a new address really but must look for another one that may exist from previous REPLY. regards, /jim From owner-dhcp-v6@bucknell.edu Sat Sep 23 01:46:29 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10085; Sat, 23 Sep 2000 01:46:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8N5gnb01107; Sat, 23 Sep 2000 01:42:49 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8N5gdb29656 for ; Sat, 23 Sep 2000 01:42:39 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-229.ip.theriver.com [206.97.58.229]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id TAA25435; Thu, 21 Sep 2000 19:07:09 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8N5b3w12415; Fri, 22 Sep 2000 22:37:03 -0700 (MST) Message-Id: <200009230537.e8N5b3w12415@grosse.bisbee.fugue.com> To: DHCPv6 discussion list cc: dhcp-v6@bucknell.edu Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Jim Bound of "Sat, 23 Sep 2000 01:02:43 -0400." <200009230502.BAA0000843899@anw.zk3.dec.com> Date: Fri, 22 Sep 2000 22:37:03 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > But if the client still has time left to use that address the connection > should not be broken as I believe that stateless addrconf as a spec is > the architecture for that decision not ours. So if a server wants to > stop a client from using an address that still has time left they should > have to send the address back to the client with a reduced lease to end > the connection and use of that address. It seems like what you are disputing is how the server notifies the client that an address must be dropped, not whether it can. Am I right? So what does this have to do with stateless address configuration? _MelloN_ From owner-dhcp-v6@bucknell.edu Sun Sep 24 08:03:03 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08157; Sun, 24 Sep 2000 08:03:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8OC0Hb24069; Sun, 24 Sep 2000 08:00:17 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8OC02b18183 for ; Sun, 24 Sep 2000 08:00:02 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Sun, 24 Sep 2000 07:59:47 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC194@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: DHCPv6 address model proposal... Date: Sun, 24 Sep 2000 07:59:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >So, that synchronization could be accomplished by >requiring that the client send its version of the >IA to the server, and the server could send back the >changes - changing the lifetimes on some addresses, >explicitly invalidating some addresses and adding new >addresses. That seems more complicated to me than the >server simply sending the client the current, correct, >complete IA. I believe, though perhaps more complicated, that this will be required. Now, it is a matter of discussion whether an "invalid" address in the client's renewal is explicitly or implicitly invalidated - the server could send back lifetimes of 0 or it could simply not return that address (the client then would either invalidate the missing address or would keep using it until the previously received lifetime expires). I think that we should allow the two different behavoirs: 1. Server explicitly responds with 0 lifetimes to force the client to invalidate the address immediately. 2. Server doesn't respond with the address (perhaps because it is no longer or never was authoritative for that address) and the client is allowed to continue using that address until the lifetime expires (since that's what the original 'lease' give it in terms of 'rights'). Note that in this case, the client MUST continue to send this address in any future renewals UNTIL it has stopped using the address (lifetime expires). I actually believe that #2 will have some value in mobility or similar environments. - Bernie Volz IPWorks, Inc. -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: Friday, September 22, 2000 3:58 PM To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... At 08:16 AM 9/22/00 -0400, Thomas Narten wrote: >I think that the only way to force a client to "invalidate" or "stop >using" an address is to explicitely tell it that it now has a zero >valid lifetime. Or, one can be silent (omit an address), but that >*does* *not* invalidate the address and cause the client to stop using >it per se. Rather, the client stops using an address when the >addresses' valid lifetime goes to zero. Can't we define explicitly define those semantics within DHCP? That is, can't we define a model in which the client and server agree that the server will send exactly the current state of the IA - the current list of addresses associated with the IA. With such a model, the server would resend every address that continues to be in the IA and drops those that are no longer in the IA. >>My comparison point is stateless addrconf. One doesn't >>conclude an address is no longer valid because routers >>stop advertising it, one stops using an address when >>its lifetime expires. I can understand the desire to be compatible with stateless autoconf. But DHCP allows for host-specific configuration information, rather than information multicast to many hosts. So the problem space is a little different, I think. I don't see where omitting some of the addresses sent from a host to a client simplifies anything - that list of addresses is just the current state for the client - while explicitly invalidating some addresses complicates the server logic by requiring that the server keep track of the client's previous state. In fact, specifically invalidating addresses complicates the protocol logic because, as Kim Kinnear pointed out to me earlier today, DHCP really manages a database of configuration information that's distributed among the server and the clients. If the server must explicitly invalidate client addresses, it must know what those addresses are. Easy enough, if the client and server are in sync. But, to guarantee correctness in the case that the client and server are out of sync, the server must know reliably what addresses the client has in the IA (the server can't assume that it's version of the IA is the same as the client's). So, that synchronization could be accomplished by requiring that the client send its version of the IA to the server, and the server could send back the changes - changing the lifetimes on some addresses, explicitly invalidating some addresses and adding new addresses. That seems more complicated to me than the server simply sending the client the current, correct, complete IA. >Note also, that a DHCP server probably *does* want to include all >addresses, including those that will become invalid *very* soon, >because other nodes may be trying to send traffic to those >addresses. Agreed... - Ralph From owner-dhcp-v6@bucknell.edu Sun Sep 24 14:27:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09846; Sun, 24 Sep 2000 14:27:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8OIOob01334; Sun, 24 Sep 2000 14:24:50 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8OIOYb00069 for ; Sun, 24 Sep 2000 14:24:35 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-77.ip.theriver.com [206.97.58.77]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id HAA02439 for ; Sat, 23 Sep 2000 07:49:04 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8OIOIe02576 for ; Sun, 24 Sep 2000 11:24:19 -0700 (MST) Message-Id: <200009241824.e8OIOIe02576@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Bernie Volz of "Sun, 24 Sep 2000 07:59:44 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC194@lespaul.process.com> Date: Sun, 24 Sep 2000 11:24:18 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > >So, that synchronization could be accomplished by requiring that > >the client send its version of the IA to the server, and the server > >could send back the changes > I believe, though perhaps more complicated, that this will be required. Why do you believe this? I don't think this is required at all, and it does create a great deal of complexity, as well as making client packets a lot fatter. Can you explain why you believe that this is necessary? _MelloN_ From owner-dhcp-v6@bucknell.edu Sun Sep 24 14:54:14 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09994; Sun, 24 Sep 2000 14:54:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8OIrwb13662; Sun, 24 Sep 2000 14:53:58 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8OIrqb10540 for ; Sun, 24 Sep 2000 14:53:52 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Sun, 24 Sep 2000 14:53:36 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC195@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: DHCPv6 address model proposal... Date: Sun, 24 Sep 2000 14:53:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >> >So, that synchronization could be accomplished by requiring that >> >the client send its version of the IA to the server, and the server >> >could send back the changes > >> I believe, though perhaps more complicated, that this will be required. > >Why do you believe this? I don't think this is required at all, and >it does create a great deal of complexity, as well as making client >packets a lot fatter. Can you explain why you believe that this is >necessary? > > _MelloN_ Ted: I explained the need for this a few days ago ... you were the one that suggested it! It has to do with the renewal time discussion - see the emails below. - Bernie Volz IPWorks, Inc. -----Original Message----- From: Bernie Volz Sent: Thursday, September 21, 2000 10:09 PM To: 'dhcp-v6@bucknell.edu' Subject: RE: renewal time Ted: The multiple server case is an interesting one to consider. I would assume that the renewals and the like will go to the SAME server and therefore the client's IA is really specific to that server. But, this does create an interesting issue for renewals that are multicast (I'm lazy at the moment and don't recall the exact "renewal" steps in DHCPv6, but I assume we're allowing multicast at some time if the original server isn't responding). And, also for any failover protocol (since the servers are different, though they are cooperating). The failover "lazy update" approach may fail since if the partner server gets a renewal before the original server updated it with information, how will the partner know what addresses to give? Urgh! This really does mean there is a reason for the client to send the list of addresses on a renewal. This would give "other" servers a hint as to what the client had and the server can determine "oh, those look like reasonable addresses to me since they aren't in use (or in use by that client)". Note also that even if the renewal is sent to the same server, it is always possible that that server lost stable storage and thus there would be no information on the server and it would assign new addresses (perhaps not the same ones) unless the client also sent the addresses with the renewal. So ... scrap my thought of saving bits and processing. - Bernie Volz IPWorks, Inc. -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Thursday, September 21, 2000 9:34 PM To: DHCPv6 discussion list Subject: Re: renewal time > I think this also means that there is no reason for the client to send the > server the list of addresses it thinks are in the IA. Why waste the bits on > the wire and the server processing time when the server will tell the client > "here's the addresses associated with this IA" in the response anyway. There is a reason: to preserve address stability. But it's not a very good reason, and I think that by default the client probably shouldn't bother to tell the DHCP server what its old address was. There's only one catch here: we have to be careful that the client doesn't get its IA whacked around by two non-cooperating DHCP servers on the same wire. _MelloN_ From owner-dhcp-v6@bucknell.edu Sun Sep 24 15:26:44 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10163; Sun, 24 Sep 2000 15:26:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8OJOPb00555; Sun, 24 Sep 2000 15:24:26 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8OJONb01245 for ; Sun, 24 Sep 2000 15:24:23 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-77.ip.theriver.com [206.97.58.77]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id IAA02589 for ; Sat, 23 Sep 2000 08:48:52 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8OJO3e03316 for ; Sun, 24 Sep 2000 12:24:03 -0700 (MST) Message-Id: <200009241924.e8OJO3e03316@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Bernie Volz of "Sun, 24 Sep 2000 14:53:35 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC195@lespaul.process.com> Date: Sun, 24 Sep 2000 12:24:03 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I explained the need for this a few days ago ... you were the one that > suggested it! It has to do with the renewal time discussion - see the emails > below. No, I said that it might be *useful* on some occasions for the client to send the address in as a hint to the server. I do not believe that it is *generally* useful. I certainly don't think the protocol should be based on the client always doing this. I also brought up the problem that a client might lose all its addresses because it connected with a different server on the same wire. Having the client say what addresses it has doesn't solve this problem, though. _MelloN_ From owner-dhcp-v6@bucknell.edu Sun Sep 24 23:28:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14190; Sun, 24 Sep 2000 23:28:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8P3QGb10493; Sun, 24 Sep 2000 23:26:16 -0400 (EDT) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8P3Q7b28637 for ; Sun, 24 Sep 2000 23:26:07 -0400 (EDT) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 8D592717B; Sun, 24 Sep 2000 23:25:52 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 3B5697173; Sun, 24 Sep 2000 23:25:52 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id XAA0000627106; Sun, 24 Sep 2000 23:24:40 -0400 (EDT) From: Jim Bound Message-Id: <200009250324.XAA0000627106@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: dhcp-v6@bucknell.edu Subject: Re: DHCPv6 address model proposal... In-reply-to: Your message of "Fri, 22 Sep 2000 22:37:03 PDT." <200009230537.e8N5b3w12415@grosse.bisbee.fugue.com> Date: Sun, 24 Sep 2000 23:24:40 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >> But if the client still has time left to use that address the connection >> should not be broken as I believe that stateless addrconf as a spec is >> the architecture for that decision not ours. So if a server wants to >> stop a client from using an address that still has time left they should >> have to send the address back to the client with a reduced lease to end >> the connection and use of that address. >It seems like what you are disputing is how the server notifies the >client that an address must be dropped, not whether it can. Am I >right? So what does this have to do with stateless address >configuration? Yes the issue is how. In the existing IPv6 implementations and deployed IPv6 nodes when a router provides a node with an address with valid and preferred lifetimes, and then later sends another router advertisement but not with prefixes previously sent. Example Router Advertisement #1 (to be used for autoconfgiguration so the A bit is set) Prefix 44fe::/64 Valid Lifetime 5 days Preferred Lifetime 4 days and 1400 hours Then Router Advertisement #2 is Prefix 33fe::/64 Valid Lifetime 5 hours Preferred Lifetime 3 hours When the second Router Advertisement #2 happens it has no affect to the first Router Advertisement. The only way the Router can stop use of the 44fe prefix is as follows: Router Advertisement #3 Prefix 4ffe::/64 Valid Lifetime 2 hours Preferred Lifetime 2 hours IPv6 does not permit a router to send a zero lifetime unless IPsec is being used with neighbor discovery. So what I am stating is that if the server sends back a Reply and there is no address in the packet which the client is still using and received from DHCPv6 the client cannot break the IPv6 connections using that address per the rules defined in stateless addrconf. The reason is that addrconf has defined a behavior and we cannot break that with a stateful protocol. Basically stateless holds some rule over the architecture for implementation. regards, /jim From owner-dhcp-v6@bucknell.edu Sun Sep 24 23:57:55 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14748; Sun, 24 Sep 2000 23:57:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8P3vJb06954; Sun, 24 Sep 2000 23:57:19 -0400 (EDT) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8P3vDb31864 for ; Sun, 24 Sep 2000 23:57:13 -0400 (EDT) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 6D32331BE; Sun, 24 Sep 2000 23:56:54 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 57BE03203 for ; Sun, 24 Sep 2000 23:56:54 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id XAA0000631053; Sun, 24 Sep 2000 23:56:18 -0400 (EDT) From: Jim Bound Message-Id: <200009250356.XAA0000631053@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-reply-to: Your message of "Sun, 24 Sep 2000 23:24:40 EDT." <200009250324.XAA0000627106@anw.zk3.dec.com> Date: Sun, 24 Sep 2000 23:56:18 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN So the renewal time will always be less than the preferred lifetime for a single address? And the renewal time will always be less than the smallest preferred lifetime for an address set provided by the server? regards, /jim From owner-dhcp-v6@bucknell.edu Mon Sep 25 06:50:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29321; Mon, 25 Sep 2000 06:50:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PAlXb17130; Mon, 25 Sep 2000 06:47:33 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PAlUb10369 for ; Mon, 25 Sep 2000 06:47:30 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Sep 2000 06:47:15 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC196@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: DHCPv6 address model proposal... Date: Mon, 25 Sep 2000 06:47:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN A new client or an existing client can always lose all of its addresses. If the client DOESN'T know its addresses, it can't supply them. However, if a client does have a record of addresses, it should supply them as a "hint" to the server. I believe that it is generally useful and should be required of the client if it has any addresses for which the lifetimes have not "expired". - Bernie Volz -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Sunday, September 24, 2000 3:24 PM To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... > I explained the need for this a few days ago ... you were the one that > suggested it! It has to do with the renewal time discussion - see the emails > below. No, I said that it might be *useful* on some occasions for the client to send the address in as a hint to the server. I do not believe that it is *generally* useful. I certainly don't think the protocol should be based on the client always doing this. I also brought up the problem that a client might lose all its addresses because it connected with a different server on the same wire. Having the client say what addresses it has doesn't solve this problem, though. _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Sep 25 06:51:35 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29463; Mon, 25 Sep 2000 06:51:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PApKb22728; Mon, 25 Sep 2000 06:51:20 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PAp6b20110 for ; Mon, 25 Sep 2000 06:51:06 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Sep 2000 06:50:51 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC197@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: DHCPv6 address model proposal... Date: Mon, 25 Sep 2000 06:50:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Jim ... I think you have it. If the server's reply does not include an address that the client previously had for that IA, the client should follow the normal rules and continue using that address until the lifetimes expire. This is just like stateless addrconf. - Bernie Volz -----Original Message----- From: Jim Bound [mailto:bound@zk3.dec.com] Sent: Sunday, September 24, 2000 11:25 PM To: DHCPv6 discussion list Cc: dhcp-v6@bucknell.edu Subject: Re: DHCPv6 address model proposal... >> But if the client still has time left to use that address the connection >> should not be broken as I believe that stateless addrconf as a spec is >> the architecture for that decision not ours. So if a server wants to >> stop a client from using an address that still has time left they should >> have to send the address back to the client with a reduced lease to end >> the connection and use of that address. >It seems like what you are disputing is how the server notifies the >client that an address must be dropped, not whether it can. Am I >right? So what does this have to do with stateless address >configuration? Yes the issue is how. In the existing IPv6 implementations and deployed IPv6 nodes when a router provides a node with an address with valid and preferred lifetimes, and then later sends another router advertisement but not with prefixes previously sent. Example Router Advertisement #1 (to be used for autoconfgiguration so the A bit is set) Prefix 44fe::/64 Valid Lifetime 5 days Preferred Lifetime 4 days and 1400 hours Then Router Advertisement #2 is Prefix 33fe::/64 Valid Lifetime 5 hours Preferred Lifetime 3 hours When the second Router Advertisement #2 happens it has no affect to the first Router Advertisement. The only way the Router can stop use of the 44fe prefix is as follows: Router Advertisement #3 Prefix 4ffe::/64 Valid Lifetime 2 hours Preferred Lifetime 2 hours IPv6 does not permit a router to send a zero lifetime unless IPsec is being used with neighbor discovery. So what I am stating is that if the server sends back a Reply and there is no address in the packet which the client is still using and received from DHCPv6 the client cannot break the IPv6 connections using that address per the rules defined in stateless addrconf. The reason is that addrconf has defined a behavior and we cannot break that with a stateful protocol. Basically stateless holds some rule over the architecture for implementation. regards, /jim From owner-dhcp-v6@bucknell.edu Mon Sep 25 07:00:43 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29544; Mon, 25 Sep 2000 07:00:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PB09b30129; Mon, 25 Sep 2000 07:00:09 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PB04b21297 for ; Mon, 25 Sep 2000 07:00:04 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Sep 2000 06:59:52 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC198@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: DHCPv6 address model proposal... Date: Mon, 25 Sep 2000 06:59:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Yes, as I understand it that is what was being proposed. There may be cases where the renewal time could be larger than the preferred lifetime, for example if the server isn't going to be renewing that address. Perhaps the preferred is the same as the valid and is 2 hours (similar to your stateless router advertisement examples where the address is going away), and hence the renewal time could be longer than 2 hours. We do need to be careful to avoid a situation when an address is going away. Suppose it is going away in 2 hours. If a new client gets a lease, if the renewal time is set to 2 hours, it will renew in 1 hour. At that 1 hour time, it will get a preferred of 1 hour. Client will renew in 30 minutes, it gets renewal time of 30 minutes. Renews in 15 ... So, we might state the renewal time as "In general, the renewal time of an IA will be less than the smallest preferred lifetime of the non-depreciated addresses in the IA." (Or something like that.) - Bernie Volz -----Original Message----- From: Jim Bound [mailto:bound@zk3.dec.com] Sent: Sunday, September 24, 2000 11:56 PM To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... So the renewal time will always be less than the preferred lifetime for a single address? And the renewal time will always be less than the smallest preferred lifetime for an address set provided by the server? regards, /jim From owner-dhcp-v6@bucknell.edu Mon Sep 25 07:39:33 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00174; Mon, 25 Sep 2000 07:39:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PBafb18103; Mon, 25 Sep 2000 07:36:43 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PBa5b07817 for ; Mon, 25 Sep 2000 07:36:05 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id HAA11579 for ; Mon, 25 Sep 2000 07:35:28 -0400 Message-Id: <200009251135.HAA11579@hygro.adsl.duke.edu> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Ted Lemon of "Fri, 22 Sep 2000 10:43:24 PDT." <200009221743.e8MHhOw00654@grosse.bisbee.fugue.com> Date: Mon, 25 Sep 2000 07:35:28 -0400 From: Thomas Narten Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted Lemon writes: > > Or, one can be silent (omit an address), but that *does* *not* > > invalidate the address and cause the client to stop using it per > > se. Rather, the client stops using an address when the addresses' > > valid lifetime goes to zero. > The way we have talked about this, the client remembers all its > addresses, and the absence of one of these addresses in the response > for an IA indicates that the client should stop using the address > immediately. One reason why the above semantics are perhaps not ideal concerns when both stateless addrconf *and* DHCPv6 happen to be sending out information about the same address. Sure, one can argue that this is a misconfiguration, but it will happen sometimes, and the protocol needs to define the correct behavior in that case. The addrconf spec says that in all cases, whenever a node gets "new" information (either from stateless addrconf or DHCP) that new information becomes definitive and supercedes any information about that address received in the past. Thus, a "new" DHCP update always overrides a previous stateless addrconf advertisement and vice versa. This choice was made to keep things simple, as it removes corner cases having to do when deciding whether to believe stateless over DHCP or vice versa. For example, if an address is being advertised by both stateless and DHCP, what happens if the DHCP server *omits* that address the next time the client renews an IA? Should the client now assume the address is no longer valid? But does it then also need to remember that it learned that address via stateless addrconf, and shouldn't invalidate it? To me, it seems cleanest to say all addresses have explicit lifetimes, and the only way to invalidate an address is: 1) have the lifetime go to zero (something the client does should it not receive an updated lifetime via DHCP or stateless addrconf) 2) Use DHCP or stateless addrconf to send an update with new lifetimes that force step 1) to happen more quickly in those cases where this is the desired outcome. Here is specific scenario where the invalidate implicitely model may result in incorrect behavior. Consider a misconfiguration where the same address is being advertised via stateless and DHCP. Suppose the sys admin determines the misconfiguration and attempts to correct it by having address/prefix advertised only via statless. The sys admin then updates the DHCP config file and on the next DHCP update, the DHCP server omits the address at question. In this case, you do not want the client to invalidate the address, as it is also being advertised by stateless. But the client would have already forgotten that information, unless it remembered the last router advertisement (something that it is not required to do). If the DHCP semantics were that an address becomes invalidated only when the lifetime reaches zero, having DHCP stop advertising the prefix would not cause the client (in this case) to improperly stop using and address. On the other hand, if the DHCP semantics resulted in invalidating an address through omission of the address, the client would invalidate the address immediately, and it would not become valid again until it received a new advertisement via stateless (this can take as long as 30 minutes, BTW). Thomas From owner-dhcp-v6@bucknell.edu Mon Sep 25 07:58:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00665; Mon, 25 Sep 2000 07:58:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PBvub20560; Mon, 25 Sep 2000 07:57:56 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PBvTb30750 for ; Mon, 25 Sep 2000 07:57:29 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Sep 2000 07:57:12 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC199@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: DHCPv6 address model proposal... Date: Mon, 25 Sep 2000 07:57:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thomas: The model I was proposing handles your situations. The DHCP server need NOT supply the address in a renewal, but that does NOT mean that the client should stop using that address. The client can continue to use that address until the lifetime expires. If the DHCP Server wants to stop the client from using the address 'now', it can do that by supplying a small (or 0) lifetime in the renewal. (The lifetime depends on what we'll allow the server to specify for lifetimes and how secure the client feels about what it receives from the server). The Server could use the following technique to remove an address: - Signal client to reconfigure - When client renews, send the address with a 0 lifetime If an address (prefix) is otherwise removed from a DHCP server configuration, the server would simply not include that address in future replies to the client. However, the client has full rights to use that address until the lifetime expires. BTW: It would not surprise me that Router Advertisements will advertise stateful prefixes (that was the design as there is a bit that specifies whether a client can autoconfigure from that prefix). That is one reason why I raised the issue early on that we need to be clear about how a client should handle this in general. What if a DHCP Server says that preferred lifetime is 20 hours and valid is 60 hours and Router Advertisements say 2 and 6 hours, respectively? Which should the client use? And depending on how you chose, consider what happens if the renewal time is 10 hours. - Bernie Volz -----Original Message----- From: Thomas Narten [mailto:narten@raleigh.ibm.com] Sent: Monday, September 25, 2000 7:35 AM To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... Ted Lemon writes: > > Or, one can be silent (omit an address), but that *does* *not* > > invalidate the address and cause the client to stop using it per > > se. Rather, the client stops using an address when the addresses' > > valid lifetime goes to zero. > The way we have talked about this, the client remembers all its > addresses, and the absence of one of these addresses in the response > for an IA indicates that the client should stop using the address > immediately. One reason why the above semantics are perhaps not ideal concerns when both stateless addrconf *and* DHCPv6 happen to be sending out information about the same address. Sure, one can argue that this is a misconfiguration, but it will happen sometimes, and the protocol needs to define the correct behavior in that case. The addrconf spec says that in all cases, whenever a node gets "new" information (either from stateless addrconf or DHCP) that new information becomes definitive and supercedes any information about that address received in the past. Thus, a "new" DHCP update always overrides a previous stateless addrconf advertisement and vice versa. This choice was made to keep things simple, as it removes corner cases having to do when deciding whether to believe stateless over DHCP or vice versa. For example, if an address is being advertised by both stateless and DHCP, what happens if the DHCP server *omits* that address the next time the client renews an IA? Should the client now assume the address is no longer valid? But does it then also need to remember that it learned that address via stateless addrconf, and shouldn't invalidate it? To me, it seems cleanest to say all addresses have explicit lifetimes, and the only way to invalidate an address is: 1) have the lifetime go to zero (something the client does should it not receive an updated lifetime via DHCP or stateless addrconf) 2) Use DHCP or stateless addrconf to send an update with new lifetimes that force step 1) to happen more quickly in those cases where this is the desired outcome. Here is specific scenario where the invalidate implicitely model may result in incorrect behavior. Consider a misconfiguration where the same address is being advertised via stateless and DHCP. Suppose the sys admin determines the misconfiguration and attempts to correct it by having address/prefix advertised only via statless. The sys admin then updates the DHCP config file and on the next DHCP update, the DHCP server omits the address at question. In this case, you do not want the client to invalidate the address, as it is also being advertised by stateless. But the client would have already forgotten that information, unless it remembered the last router advertisement (something that it is not required to do). If the DHCP semantics were that an address becomes invalidated only when the lifetime reaches zero, having DHCP stop advertising the prefix would not cause the client (in this case) to improperly stop using and address. On the other hand, if the DHCP semantics resulted in invalidating an address through omission of the address, the client would invalidate the address immediately, and it would not become valid again until it received a new advertisement via stateless (this can take as long as 30 minutes, BTW). Thomas From owner-dhcp-v6@bucknell.edu Mon Sep 25 08:05:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00900; Mon, 25 Sep 2000 08:05:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PC53b12255; Mon, 25 Sep 2000 08:05:04 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PC4ab10400 for ; Mon, 25 Sep 2000 08:04:41 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Sep 2000 08:04:21 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC19A@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: FW: DHCP server startup announcement Date: Mon, 25 Sep 2000 08:04:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Folks ... (I think there may have been a previous discussion on the V6 list about this but I could be wrong), but should we not consider perhaps a better model than having clients periodically send SOLICIT messages? Perhaps a "Server-Started" message could be use instead? This would notify clients that are on the link that a server is present and that they may want to retry SOLICITs. Now, while this works well for clients that are on the same physical link, it is less clear how this would work when relays are included in the configuration (especially if the relays are also not on the same physical link as the server). So, perhaps this is a brain-dead idea because of these issues. - Bernie Volz -----Original Message----- From: Erik Guttman [mailto:Erik.Guttman@germany.sun.com] Sent: Monday, September 25, 2000 3:00 AM To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: Re: DHCP server startup announcement Stuart Cheshire wrote: > When a DHCP client fails to find a DHCP server, it typically keeps > broadcasting DHCP DISCOVERs at a low rate (e.g. one every five minutes). ... > One thought that occurs to me is that we could borrow from > draft-ietf-dhc-pv4-reconfigure-01.txt -- the server could broadcast a > FORCERENEW (perhaps with all zeroes in the chaddr field) effectively > saying, "To any client that currently has no server-assigned address, and > would like one, a server is now available for you to send a DISCOVER." I fully support this direction. This will make it much easier for auto configured clients to discover DHCP servers. One of the problems with the 'polling model' is that devices will discover the DHCP server at different times. During this 'transition' phase, some devices could potentially be unable to communicate. This could be avoided by having devices discover the DHCP server through an announcement and transition en masse. Considering that - there should be some randomizing interval so that hosts that receive the FORCERENEW don't all try to hit the DHCP server at once :-) Erik From owner-dhcp-v6@bucknell.edu Mon Sep 25 10:18:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04104; Mon, 25 Sep 2000 10:18:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PEIEb01882; Mon, 25 Sep 2000 10:18:15 -0400 (EDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PEHxb11279 for ; Mon, 25 Sep 2000 10:17:59 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA12488 for ; Mon, 25 Sep 2000 10:17:42 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA31632 for ; Mon, 25 Sep 2000 10:17:42 -0400 Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id KAA16079 for ; Mon, 25 Sep 2000 10:17:36 -0400 Message-Id: <200009251417.KAA16079@rotala.raleigh.ibm.com> To: DHCPv6 discussion list Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 o n Co nference Call Agenda) In-Reply-To: Message from Bernie Volz of "Fri, 08 Sep 2000 08:19:57 EDT." <63D30D6E10CFD11190A90000F805FE8602BEC0E3@lespaul.process.com> Date: Mon, 25 Sep 2000 10:17:36 -0400 From: Thomas Narten Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Responding to some very old mail... Bernie Volz writes: > BTW: If there are no router advertisements received (after some period), I > assume a IPv6 host is supposed to attempt stateful address configuration (by > default). RFC 2462 sez: 5.5.2. Absence of Router Advertisements If a link has no routers, a host MUST attempt to use stateful autoconfiguration to obtain addresses and other configuration information. An implementation MAY provide a way to disable the invocation of stateful autoconfiguration in this case, but the default SHOULD be enabled. From the perspective of autoconfiguration, a link has no routers if no Router Advertisements are received after having sent a small number of Router Solicitations as described in [DISCOVERY]. Thomas From owner-dhcp-v6@bucknell.edu Mon Sep 25 10:23:13 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04177; Mon, 25 Sep 2000 10:23:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PEMdb25781; Mon, 25 Sep 2000 10:22:39 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PEMOb30739 for ; Mon, 25 Sep 2000 10:22:24 -0400 (EDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA02192; Mon, 25 Sep 2000 07:22:20 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id HAA13261; Mon, 25 Sep 2000 07:22:12 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8PEMBa834880; Mon, 25 Sep 2000 07:22:11 -0700 (PDT) Date: Thu, 21 Sep 2000 13:02:21 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DHCPv6 address model proposal... To: DHCPv6 discussion list Cc: Erik Nordmark , DHCPv6 discussion list In-Reply-To: "Your message with ID" <200009210704.e8L74t309418@grosse.bisbee.fugue.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > > > Hmm, it isn't obvious that we need another way to invalidate an address > > (by leaving it out from the IA). Isn't it sufficient to be explicit about > > invalidating an address by including it with a zero valid and preferred > > lifetime? > > This requires the server to remember that the client had that address, > so it's actually not a simplification - it makes additional work for > the server, which now has to track the administrative removal of > non-renewable addresses. Got it. Thanks. Erik From owner-dhcp-v6@bucknell.edu Mon Sep 25 11:38:43 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06241; Mon, 25 Sep 2000 11:38:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PFZib25568; Mon, 25 Sep 2000 11:35:48 -0400 (EDT) Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PFZXb06127 for ; Mon, 25 Sep 2000 11:35:33 -0400 (EDT) Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345) id CBF171341; Mon, 25 Sep 2000 10:35:17 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 8458213AB for ; Mon, 25 Sep 2000 10:35:17 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id LAA0000690395; Mon, 25 Sep 2000 11:34:33 -0400 (EDT) From: Jim Bound Message-Id: <200009251534.LAA0000690395@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-reply-to: Your message of "Mon, 25 Sep 2000 06:50:50 EDT." <63D30D6E10CFD11190A90000F805FE8602BEC197@lespaul.process.com> Date: Mon, 25 Sep 2000 11:34:33 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >Jim ... I think you have it. If the server's reply does not include an >address that the client previously had for that IA, the client should follow >the normal rules and continue using that address until the lifetimes expire. > >This is just like stateless addrconf. Exactly. We cannot break existing Ipv6 implementations either with DHCPv6 or rebuild the stateless architecture at this point. Not that anyone has proposed that but want to make sure we as a group understand any boundaries we have for IPv6. regards, /jim From owner-dhcp-v6@bucknell.edu Mon Sep 25 12:15:15 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07441; Mon, 25 Sep 2000 12:15:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PGCqb31068; Mon, 25 Sep 2000 12:12:52 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PGCfb00315 for ; Mon, 25 Sep 2000 12:12:41 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA02308 for ; Mon, 25 Sep 2000 12:12:25 -0400 (EDT) Message-Id: <4.3.1.2.20000925120645.00bb9c70@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 25 Sep 2000 12:14:40 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: DHCPv6 address model proposal... In-Reply-To: <200009251135.HAA11579@hygro.adsl.duke.edu> References: <200009221743.e8MHhOw00654@grosse.bisbee.fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Tomas - in general I see your point. In the particular case you cite: At 07:35 AM 9/25/00 -0400, Thomas Narten wrote: >For example, if an address is being advertised by both stateless and >DHCP, what happens if the DHCP server *omits* that address the next >time the client renews an IA? Should the client now assume the address >is no longer valid? But does it then also need to remember that it >learned that address via stateless addrconf, and shouldn't invalidate >it? According to the stateful/stateless interaction rule: "a "new" DHCP update always overrides a previous stateless addrconf advertisement and vice versa." I would interpret that rule to say that the DHCP message overrides the stateless addrconf and the client should invalidate the address... The more interesting case might be if a stateless addrconf message advertises a prefix unknown to the DHCP server. In the case of implicit invalidation ("invalidation b omission"), what does the client do if the DHCP server does not return an address within that prefix in the IA? Here's another interesting case: what does the client do in the server explicitly invalidates an address within a prefix advertised by stateless addrconf? Under what circumstances would a host be using both stateful and stateless addrconf? Of course, I may be confused about the operation of stateless addrconf; please feel free to correct me (as gently as possible!)... - Ralph From owner-dhcp-v6@bucknell.edu Mon Sep 25 12:21:10 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07694; Mon, 25 Sep 2000 12:21:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PGKmb25966; Mon, 25 Sep 2000 12:20:48 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PGKfb16144 for ; Mon, 25 Sep 2000 12:20:41 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id FAA06846; Sun, 24 Sep 2000 05:45:09 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PGIlp00938; Mon, 25 Sep 2000 09:18:47 -0700 (MST) Message-Id: <200009251618.e8PGIlp00938@grosse.bisbee.fugue.com> To: DHCPv6 discussion list cc: dhcp-v6@bucknell.edu Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Jim Bound of "Sun, 24 Sep 2000 23:24:40 -0400." <200009250324.XAA0000627106@anw.zk3.dec.com> Date: Mon, 25 Sep 2000 09:18:47 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > So what I am stating is that if the server sends back a Reply and there > is no address in the packet which the client is still using and received > from DHCPv6 the client cannot break the IPv6 connections using that address > per the rules defined in stateless addrconf. Yes, I understand that. But you are talking about an implementation detail, rather than about a goal. It seems like the goal is that the protocol should not cause a client to drop an address when it doesn't have to. Right? I'm very uncomfortable with drawing parallels to stateless address configuration. The current draft does things the way stateless address configuration does them, and because this is a state*ful* protocol and not a state*less* one, this makes the protocol more difficult to understand and implement than it needs to be, IMHO. _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Sep 25 12:30:45 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07834; Mon, 25 Sep 2000 12:30:45 -0400 (EDT) Received: from localhost (LOCALHOST [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PGUHb12298; Mon, 25 Sep 2000 12:30:18 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PGTvb19283 for ; Mon, 25 Sep 2000 12:29:58 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id FAA06871 for ; Sun, 24 Sep 2000 05:54:25 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PGSgp01068 for ; Mon, 25 Sep 2000 09:28:42 -0700 (MST) Message-Id: <200009251628.e8PGSgp01068@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Bernie Volz of "Mon, 25 Sep 2000 06:47:13 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC196@lespaul.process.com> Date: Mon, 25 Sep 2000 09:28:42 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I believe that it is generally useful and should be required of the client > if it has any addresses for which the lifetimes have not "expired". Right, but why do you believe this? We're talking about a lot of bytes, and a lot of extra processing on the server, so I'd like to see some justification for why this is useful. Can you give me an example where the server's behaviour would change based on this information? _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Sep 25 12:33:56 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07933; Mon, 25 Sep 2000 12:33:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PGXYb11457; Mon, 25 Sep 2000 12:33:34 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PGXLb04573 for ; Mon, 25 Sep 2000 12:33:21 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id FAA06887 for ; Sun, 24 Sep 2000 05:57:51 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PGW7p01125 for ; Mon, 25 Sep 2000 09:32:07 -0700 (MST) Message-Id: <200009251632.e8PGW7p01125@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Thomas Narten of "Mon, 25 Sep 2000 07:35:28 -0400." <200009251135.HAA11579@hygro.adsl.duke.edu> Date: Mon, 25 Sep 2000 09:32:07 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Okay, I think I can agree then that the absence of an address in a DHCPreply should not cause the client to drop that address. I prefer the other way, but don't have a strong reason for preferring it, and you've given a good reason for preferring this way. :'} _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Sep 25 12:47:55 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08190; Mon, 25 Sep 2000 12:47:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PGjIb04388; Mon, 25 Sep 2000 12:45:18 -0400 (EDT) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PGj5b28049 for ; Mon, 25 Sep 2000 12:45:05 -0400 (EDT) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id AFD2E6F1; Mon, 25 Sep 2000 12:44:57 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 98B892934; Mon, 25 Sep 2000 12:44:57 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id MAA0000696990; Mon, 25 Sep 2000 12:43:38 -0400 (EDT) From: Jim Bound Message-Id: <200009251643.MAA0000696990@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: dhcp-v6@bucknell.edu Subject: Re: DHCPv6 address model proposal... In-reply-to: Your message of "Mon, 25 Sep 2000 09:18:47 PDT." <200009251618.e8PGIlp00938@grosse.bisbee.fugue.com> Date: Mon, 25 Sep 2000 12:43:38 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >> So what I am stating is that if the server sends back a Reply and there >> is no address in the packet which the client is still using and received >> from DHCPv6 the client cannot break the IPv6 connections using that address >> per the rules defined in stateless addrconf. > >Yes, I understand that. But you are talking about an implementation >detail, rather than about a goal. It seems like the goal is that the >protocol should not cause a client to drop an address when it doesn't >have to. Right? Yes that is right. But I do think we will get into situations in the spec where we can either be silent or state what is to happen. I think the mail Ralph just sent to Thomas on stateless will open more light to this issue for discussion. I will not respond and let Thomas respond. Having implemented stateless this is very tricky stuff and what I would hope is we learn from that experience and from all the IPv6 implementors. But I am in agreement with Bernies comments in this space and issues. For the protocol specification. >I'm very uncomfortable with drawing parallels to stateless address >configuration. The current draft does things the way stateless >address configuration does them, and because this is a state*ful* >protocol and not a state*less* one, this makes the protocol more >difficult to understand and implement than it needs to be, IMHO. I think we need to just make sure we don't break stateless stuff and why I think we are groking all this now. In defense of the current draft we did add the stateful parts where appropriate. But we are now trying to reduce complexity with things like the IA. So I think we will reach less complexity from the mail I see. But we cannot ignore the stateful effect to implementations of stateless is the key point we must make sure in our design choices for the next version of dhcpv6. But Mike will send out some questions we have today on all the threads so we can write this stuff down. One will be the entire IA use and definition and lots of questions and clarification of that. For now I am just assuming it will work and treating it as opaque but we need to have detailed discussion of the IA. regards, /jim _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Sep 25 13:02:28 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08500; Mon, 25 Sep 2000 13:02:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PH23b08834; Mon, 25 Sep 2000 13:02:03 -0400 (EDT) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PH1xb09206 for ; Mon, 25 Sep 2000 13:01:59 -0400 (EDT) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 415926209; Mon, 25 Sep 2000 13:01:43 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 290DFB78 for ; Mon, 25 Sep 2000 13:01:43 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id NAA0000698240; Mon, 25 Sep 2000 13:01:42 -0400 (EDT) From: Jim Bound Message-Id: <200009251701.NAA0000698240@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: NOTE on October dates not good for IPv6 folks Date: Mon, 25 Sep 2000 13:01:42 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph, FYI many of us will be at the IPv6 U.S. Summit on Oct 18-20 in Wash D.C. so if we plan meetings I ask they not happen at this time. We will be missing a few of us and both ADs (Thomas is speaking here too) and I assume Erik will be there too. I have to be there as Chair of the IPv6 Forum Technical Directorate and many of those folks will be there I hope too like Francis Dupont and other IPv6 implementors. http://www.ipv6forum.com/ (tech directorate listed here on the page) Here is URL of the event too if folks want to attend. http://www.xiwt.org/XIWT-IPv6/meetingsite.html The target audience for this particular IPv6 Summit are the ISPs and Telco providers. thanks /jim From owner-dhcp-v6@bucknell.edu Mon Sep 25 14:32:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10307; Mon, 25 Sep 2000 14:32:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PIVLb10635; Mon, 25 Sep 2000 14:31:21 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PIUeb02223 for ; Mon, 25 Sep 2000 14:30:40 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Sep 2000 14:30:22 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC1A0@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: DHCPv6 address model proposal... Date: Mon, 25 Sep 2000 14:30:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted ... as you cut and paste messages, it is often difficult to recall the exact context. I believe you are asking why the client should be sending all of its addresses in a renewal? If so, I already gave you my reasons. It is important for: - Failover - lazy update would not work otherwise - Multiple server situations - Loss of server's stable storage These are *ALL* examples of where the server's behavoir (under certain circumstances) would be changed based on this information because if it wasn't there the renewal might get completely different addresses UNLESS you tell me that the way a server "calculates" an address is a fixed algorithm (in which case why have the IA at all as we want to be able to give the client multiple addresses). - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Monday, September 25, 2000 12:29 PM To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... > I believe that it is generally useful and should be required of the client > if it has any addresses for which the lifetimes have not "expired". Right, but why do you believe this? We're talking about a lot of bytes, and a lot of extra processing on the server, so I'd like to see some justification for why this is useful. Can you give me an example where the server's behaviour would change based on this information? _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Sep 25 15:39:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11922; Mon, 25 Sep 2000 15:39:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PJcvb01509; Mon, 25 Sep 2000 15:38:57 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PJcmb01957 for ; Mon, 25 Sep 2000 15:38:48 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id JAA07502 for ; Sun, 24 Sep 2000 09:03:17 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PJajp03718 for ; Mon, 25 Sep 2000 12:36:45 -0700 (MST) Message-Id: <200009251936.e8PJajp03718@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Bernie Volz of "Mon, 25 Sep 2000 14:30:21 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC1A0@lespaul.process.com> Date: Mon, 25 Sep 2000 12:36:45 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > These are *ALL* examples of where the server's behavoir (under certain > circumstances) would be changed based on this information because if it > wasn't there the renewal might get completely different addresses UNLESS you > tell me that the way a server "calculates" an address is a fixed algorithm > (in which case why have the IA at all as we want to be able to give the > client multiple addresses). If the client is renewing, it's unicasting to the server, not broadcasting, right? Actually, now that I think about it, I don't know that this is true - do DHCPrequest messages go to the server's address or to a multicast address? Hm, this is interesting. There does not appear to be a mechanism in the specification for what happens if the client has a valid IA, tries to renew it, and gets no response. There doesn't seem to be anything in the spec at all about renewal, other than a brief blurb on releasable resources. _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Sep 25 16:05:55 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12452; Mon, 25 Sep 2000 16:05:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PK3Sb22739; Mon, 25 Sep 2000 16:03:28 -0400 (EDT) Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PK3Eb20362 for ; Mon, 25 Sep 2000 16:03:15 -0400 (EDT) Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345) id 3344F119A; Mon, 25 Sep 2000 15:02:58 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 8372D10DD for ; Mon, 25 Sep 2000 15:02:57 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id QAA0000713658; Mon, 25 Sep 2000 16:02:26 -0400 (EDT) From: Jim Bound Message-Id: <200009252002.QAA0000713658@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-reply-to: Your message of "Mon, 25 Sep 2000 12:36:45 PDT." <200009251936.e8PJajp03718@grosse.bisbee.fugue.com> Date: Mon, 25 Sep 2000 16:02:26 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >If the client is renewing, it's unicasting to the server, not >broadcasting, right? Actually, now that I think about it, I don't >know that this is true - do DHCPrequest messages go to the server's >address or to a multicast address? Nope. Request is unicast only. If you go to section 3 of the current spec DHCP Constants you will see all the Multicast Addresses we use for DHCPv6 and they are also all assigned by IANA as Bob Hinden did this for the IPv6 Addr Arch. But we never had request as Multicast. >Hm, this is interesting. There does not appear to be a mechanism in >the specification for what happens if the client has a valid IA, tries >to renew it, and gets no response. There doesn't seem to be anything >in the spec at all about renewal, other than a brief blurb on >releasable resources. Its also in 11.4.2 section under Request Retransmit. The current specs version of an IA is the link-local address + prefix for that link. The client does not try to renew the IA as the concept is new from our design discussions. The spec was written with the intention that link-local and prefix of link will be unique and it is in IPv6, except when a node changes its link-local now because of privacy concerns and uses anonymous addresses. I think we have a fix for this that can be used by the IA too in our new design for the client identifier but that should be its own mail message and thread and Mike should be sending something on this as far as questions shortly. So the client in the present spec does not have an IA to renew but we did put in how to retransmit a request and I think we will have to do the same with an IA. As far as releasable resources we stayed away from that except for the actual address per the working groups input for sometime now. regards, /jim From owner-dhcp-v6@bucknell.edu Mon Sep 25 16:06:45 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12496; Mon, 25 Sep 2000 16:06:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PK6Qb25975; Mon, 25 Sep 2000 16:06:26 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PK6Eb32662 for ; Mon, 25 Sep 2000 16:06:15 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Sep 2000 16:05:59 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC1A3@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: DHCPv6 address model proposal... Date: Mon, 25 Sep 2000 16:05:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Yeah ... I looked through the spec the other day and couldn't find this discussed either. I thought perhaps I just wasn't looking the right place. Perhaps the DHCPv6 model is that the client must go back through the entire cycle to locate a server? In that case, having the ability to provide a list ("gee, I'd like these addresses - can I have them please!") would be greatly useful. Sometimes I've been falling back into the DHCPv4 mode in our discussions ... and in that case, certainly having the client send the address is absolutely critical to the proper operation of DHCPv4 (we trust the client in failover and at other times). And, as DHCPv6 has similar goals and requirements (at least in my mind), I can't see how this fundamental issue should be changed. - Bernie Volz -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Monday, September 25, 2000 3:37 PM To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... > These are *ALL* examples of where the server's behavoir (under certain > circumstances) would be changed based on this information because if it > wasn't there the renewal might get completely different addresses UNLESS you > tell me that the way a server "calculates" an address is a fixed algorithm > (in which case why have the IA at all as we want to be able to give the > client multiple addresses). If the client is renewing, it's unicasting to the server, not broadcasting, right? Actually, now that I think about it, I don't know that this is true - do DHCPrequest messages go to the server's address or to a multicast address? Hm, this is interesting. There does not appear to be a mechanism in the specification for what happens if the client has a valid IA, tries to renew it, and gets no response. There doesn't seem to be anything in the spec at all about renewal, other than a brief blurb on releasable resources. _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Sep 25 17:04:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14014; Mon, 25 Sep 2000 17:04:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PL1hb19767; Mon, 25 Sep 2000 17:01:43 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PL1Xb17745 for ; Mon, 25 Sep 2000 17:01:33 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id KAA07740 for ; Sun, 24 Sep 2000 10:26:02 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PKxsp04814 for ; Mon, 25 Sep 2000 13:59:59 -0700 (MST) Message-Id: <200009252059.e8PKxsp04814@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Jim Bound of "Mon, 25 Sep 2000 16:02:26 -0400." <200009252002.QAA0000713658@anw.zk3.dec.com> Date: Mon, 25 Sep 2000 13:59:54 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > So the client in the present spec does not have an IA to renew but we > did put in how to retransmit a request and I think we will have to do > the same with an IA. Right, but what happens if the DHCP server the client contacted previously is down when it tries to renew? It can retry all it wants, but it won't get a response. Does it just time out and let its connections die, or does it try to contact any other DHCP server that may be present on the wire to see if it can get that DHCP server to renew the IA with the same addresses? This is the equivalent of the transition between RENEWING and REBINDING in DHCPv4. I don't see anything like that in the current draft. Is this omission intentional? _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Sep 25 17:07:52 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14140; Mon, 25 Sep 2000 17:07:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PL6Xb27255; Mon, 25 Sep 2000 17:06:33 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PL6Vb08515 for ; Mon, 25 Sep 2000 17:06:31 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id KAA07752 for ; Sun, 24 Sep 2000 10:30:59 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PL4vp04888 for ; Mon, 25 Sep 2000 14:04:57 -0700 (MST) Message-Id: <200009252104.e8PL4vp04888@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Bernie Volz of "Mon, 25 Sep 2000 16:05:58 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC1A3@lespaul.process.com> Date: Mon, 25 Sep 2000 14:04:56 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > And, as DHCPv6 has similar goals and requirements (at > least in my mind), I can't see how this fundamental issue should be changed. When the client is contacting a server with which it has an existing collection of addresses for an identity association, it should not be necessary for it to resend its current addresses. And if it is only using its current addresses as care-of addresses, likewise I think it doesn't need to send it. However, if we can get into something like a REBINDING state, *then* it needs to send its current set of addresses, so that the other server in a failover pair has the opportunity to renew them. I don't think it needs to send its addresses on startup - in the DHCPsolicit message - because at that time presumably it does not have any outstanding connections on addresses in the identity association, so it has nothing to lose if the secondary gives it a different address. So I see only one case where this is important: REBIND. And the current draft doesn't do REBIND. I think it should do REBIND, and when it does, I think the REBIND request should include a list of addresses. Would that satisfy your concern? If we conclude that we *don't* need REBIND, do you think there is a case where the client still needs to send its current address list? _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Sep 25 17:41:45 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15083; Mon, 25 Sep 2000 17:41:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PLdRb09774; Mon, 25 Sep 2000 17:39:27 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PLdDb24642 for ; Mon, 25 Sep 2000 17:39:13 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Sep 2000 17:38:57 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC1A8@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: DHCPv6 address model proposal... Date: Mon, 25 Sep 2000 17:38:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted: Your analysis I think covers the issue. The REBIND case is really the only one. We have been taking about clients needing to "renew" the leases so isn't that a REBIND? If the client never goes back to the server to "renew" the addresses, then we don't need to send them. And, agreed that we only need to send them in a rebind case. If a client has no addresses, it can't send them; I never expected them to be sent in a SOLICIT. - Bernie Volz IPWorks, Inc. -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Monday, September 25, 2000 5:05 PM To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... > And, as DHCPv6 has similar goals and requirements (at > least in my mind), I can't see how this fundamental issue should be changed. When the client is contacting a server with which it has an existing collection of addresses for an identity association, it should not be necessary for it to resend its current addresses. And if it is only using its current addresses as care-of addresses, likewise I think it doesn't need to send it. However, if we can get into something like a REBINDING state, *then* it needs to send its current set of addresses, so that the other server in a failover pair has the opportunity to renew them. I don't think it needs to send its addresses on startup - in the DHCPsolicit message - because at that time presumably it does not have any outstanding connections on addresses in the identity association, so it has nothing to lose if the secondary gives it a different address. So I see only one case where this is important: REBIND. And the current draft doesn't do REBIND. I think it should do REBIND, and when it does, I think the REBIND request should include a list of addresses. Would that satisfy your concern? If we conclude that we *don't* need REBIND, do you think there is a case where the client still needs to send its current address list? _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Sep 25 18:42:56 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16648; Mon, 25 Sep 2000 18:42:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PMeRb01050; Mon, 25 Sep 2000 18:40:27 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PMeNb02151 for ; Mon, 25 Sep 2000 18:40:23 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id MAA08013 for ; Sun, 24 Sep 2000 12:04:51 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PMcep06075 for ; Mon, 25 Sep 2000 15:38:42 -0700 (MST) Message-Id: <200009252238.e8PMcep06075@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Bernie Volz of "Mon, 25 Sep 2000 17:38:56 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC1A8@lespaul.process.com> Date: Mon, 25 Sep 2000 15:38:40 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > The REBIND case is really the only one. We have been taking about > clients needing to "renew" the leases so isn't that a REBIND? No. REBIND is when the client has already tried to renew the lease by contacting the server from which it got the lease using a unicast message. Time is running out, so it decides to see if it can contact another server using multicast (broadcast in the DHCPv4 case). REBINDING and RENEWING are two distinct states, and REBINDING is specifically for cases where the old server can't be contacted. I do not think it is necessary for the client to send an address list in the RENEWING case - only in the REBINDING case. _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Sep 25 19:51:05 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17657; Mon, 25 Sep 2000 19:51:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PNm6b04247; Mon, 25 Sep 2000 19:48:06 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PNm0b04992 for ; Mon, 25 Sep 2000 19:48:00 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Sep 2000 19:47:44 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC1A9@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: DHCPv6 address model proposal... Date: Mon, 25 Sep 2000 19:47:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN OK (I guess I should brush up on my DHCP terminology). The only benefit from sending the list in the RENEWING case is the case where the server has lost stable storage. In that case, if would have NO record of the addresses and would be forced to determine new ones. So, we can decide whether that one case is worth it. -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Monday, September 25, 2000 6:39 PM To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... > The REBIND case is really the only one. We have been taking about > clients needing to "renew" the leases so isn't that a REBIND? No. REBIND is when the client has already tried to renew the lease by contacting the server from which it got the lease using a unicast message. Time is running out, so it decides to see if it can contact another server using multicast (broadcast in the DHCPv4 case). REBINDING and RENEWING are two distinct states, and REBINDING is specifically for cases where the old server can't be contacted. I do not think it is necessary for the client to send an address list in the RENEWING case - only in the REBINDING case. _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Sep 25 20:19:05 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18160; Mon, 25 Sep 2000 20:19:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8Q0Idb20140; Mon, 25 Sep 2000 20:18:39 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8Q0IQb25262 for ; Mon, 25 Sep 2000 20:18:26 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id NAA08350 for ; Sun, 24 Sep 2000 13:42:54 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8Q0Gcp07419 for ; Mon, 25 Sep 2000 17:16:38 -0700 (MST) Message-Id: <200009260016.e8Q0Gcp07419@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Bernie Volz of "Mon, 25 Sep 2000 19:47:43 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC1A9@lespaul.process.com> Date: Mon, 25 Sep 2000 17:16:38 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > The only benefit from sending the list in the RENEWING case is the > case where the server has lost stable storage. Realistically, I don't think this is a problem significant enough to be worth trying to solve - this is a fairly unlikely event. Also, if the server loses stable storage, it would be sheer luck if any given client were able to get back its old set of addresses before some other client got it, even if we did insist that clients always send back all their addresses in every renewal request. So it's a pretty high price to pay for a pretty low return. _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Sep 26 01:39:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28207; Tue, 26 Sep 2000 01:39:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8Q5ZVb32088; Tue, 26 Sep 2000 01:35:31 -0400 (EDT) Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8Q5ZHb16894 for ; Tue, 26 Sep 2000 01:35:18 -0400 (EDT) Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345) id 88DD23040; Tue, 26 Sep 2000 00:35:02 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id BAB1830A5 for ; Tue, 26 Sep 2000 00:35:01 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id BAA0000806480; Tue, 26 Sep 2000 01:34:14 -0400 (EDT) From: Jim Bound Message-Id: <200009260534.BAA0000806480@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-reply-to: Your message of "Mon, 25 Sep 2000 13:59:54 PDT." <200009252059.e8PKxsp04814@grosse.bisbee.fugue.com> Date: Tue, 26 Sep 2000 01:33:52 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >> So the client in the present spec does not have an IA to renew but we >> did put in how to retransmit a request and I think we will have to do >> the same with an IA. >Right, but what happens if the DHCP server the client contacted >previously is down when it tries to renew? It can retry all it >wants, but it won't get a response. Does it just time out and let >its connections die, or does it try to contact any other DHCP server >that may be present on the wire to see if it can get that DHCP server >to renew the IA with the same addresses? This was one of our questions in Pittsburgh we did not get to. What we had previously was that the client would go back to solicit. But in the current draft we did a lot of work to make the client be able to talk with multiple servers. So we left it blank in the spec for discussion. The reason is in the current draft the client could specifically keep server advertisements for later purposes possibly at lower preference value than the server that was chosen for the requst. So we were not sure what consensus was and it was TBD as we know the WG wanted more than we had done thus far and going back to solicit would not be needd if the client had another server address. >This is the equivalent of the transition between RENEWING and >REBINDING in DHCPv4. I don't see anything like that in the current >draft. Is this omission intentional? Yes it was. Note we also had the R bit in the Request if the client rebooted which would signal a rebind too. But thats a hack and we need to fix that this time around with the IA strategy. But I am thinking with the IA and your model dhcpv6 would even be more idempotent than now with respect to REBIND or RENEW. A clear advantage of your model. But we should nail down this time if the REQUEST Fails what to do? I think we should permit clients to use other server if known but report error to console and log (with out getting into implementation details) and if it don't have a server then begin SOLICIT if that fails then there is a network problem. At the server the same addresses and lease will exist for that IA. Hence, the server just sends the addresses again. Because we have changed the model for addresses from what it is at the server its static and won't matter. This fixes the bug we had in dhcpv6 current draft IMO. Also pretty easy to implement. Well it might be to strong to say bug above but it certainly removes a whole bunch of complexity with the IA model or really the new address model. We still need to figure out what exactly is the IA? p.s. In New Jersey for IPv6 customer that has requested person who knows how to implement IPv6. I am in Red Roof Inn typing this. I won't see mail till tomorrow night or early wednesday. regards, /jim _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Sep 26 06:19:50 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08394; Tue, 26 Sep 2000 06:19:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8QAHHb14031; Tue, 26 Sep 2000 06:17:17 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8QAHEb06727 for ; Tue, 26 Sep 2000 06:17:14 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id GAA02068 for ; Tue, 26 Sep 2000 06:16:44 -0400 Message-Id: <200009261016.GAA02068@hygro.adsl.duke.edu> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Jim Bound of "Mon, 25 Sep 2000 16:02:26 EDT." <200009252002.QAA0000713658@anw.zk3.dec.com> Date: Tue, 26 Sep 2000 06:16:44 -0400 From: Thomas Narten Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi Jim, > Its also in 11.4.2 section under Request Retransmit. The current specs > version of an IA is the link-local address + prefix for that link. The > client does not try to renew the IA as the concept is new from our > design discussions. The spec was written with the intention that > link-local and prefix of link will be unique and it is in IPv6, except > when a node changes its link-local now because of privacy concerns and > uses anonymous addresses. To clarify, in the current version of anonymous addresses (draft-ietf-ipngwg-addrconf-privacy-03.txt) link-local (and site-local) addresses do not change and are not made anonymous. Only global addresses are subject to being anonymized. Thomas From owner-dhcp-v6@bucknell.edu Tue Sep 26 11:33:40 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11164; Tue, 26 Sep 2000 11:33:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8QFTab02177; Tue, 26 Sep 2000 11:29:36 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8QFTUb06623 for ; Tue, 26 Sep 2000 11:29:32 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22578 for ; Tue, 26 Sep 2000 09:29:29 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA29868 for ; Tue, 26 Sep 2000 11:29:27 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e8QFStl108346 for ; Tue, 26 Sep 2000 11:28:55 -0400 (EDT) Message-Id: <200009261528.e8QFStl108346@thunk.east.sun.com> From: Bill Sommerfeld To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-reply-to: Your message of "Mon, 25 Sep 2000 17:16:38 PDT." <200009260016.e8Q0Gcp07419@grosse.bisbee.fugue.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 26 Sep 2000 11:28:55 -0400 Sender: owner-dhcp-v6@bucknell.edu X-Sender: sommerfeld@thunk.east.sun.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Also, if the server loses stable storage, it would be sheer luck if > any given client were able to get back its old set of addresses > before some other client got it Given the size of the v6 address space and the standard subnet size, I'd say that the probabilities are (or could be engineered to be) on the side of non-reuse. - Bill From owner-dhcp-v6@bucknell.edu Tue Sep 26 12:37:16 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12028; Tue, 26 Sep 2000 12:37:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8QGYJb27554; Tue, 26 Sep 2000 12:34:19 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8QGY5b23009 for ; Tue, 26 Sep 2000 12:34:05 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-141.ip.theriver.com [206.97.58.141]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id FAA12218; Mon, 25 Sep 2000 05:58:29 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8QGVUA00806; Tue, 26 Sep 2000 09:31:31 -0700 (MST) Message-Id: <200009261631.e8QGVUA00806@grosse.bisbee.fugue.com> To: DHCPv6 discussion list cc: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Bill Sommerfeld of "Tue, 26 Sep 2000 11:28:55 -0400." <200009261528.e8QFStl108346@thunk.east.sun.com> Date: Tue, 26 Sep 2000 09:31:30 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Given the size of the v6 address space and the standard subnet size, > I'd say that the probabilities are (or could be engineered to be) on > the side of non-reuse. Yup. Sounds like stateless addrconf. _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Sep 26 12:56:11 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12432; Tue, 26 Sep 2000 12:56:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8QGtmb20716; Tue, 26 Sep 2000 12:55:48 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8QGtYb24027 for ; Tue, 26 Sep 2000 12:55:34 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Sep 2000 12:55:19 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC1B4@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: DHCPv6 address model proposal... Date: Tue, 26 Sep 2000 12:55:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In fact, with duplicate address detection and the huge address space, a server maybe could even chose to not store any information about a client. If the addresses are assigned by incrementing a counter or some such mechansim, it would not need to really remember (except of course if we didn't send the addresses in the RENEWAL request in which case it must). I'm not arguing for server implemnetations to do this or even be allowed to do it. And this would really be more of the stateless addrconf instead of stateful - except of course that a server could have a list of "allowed" clients and only respond with addresses to those clients that were in that list. - Bernie Volz -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Tuesday, September 26, 2000 12:32 PM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... > Given the size of the v6 address space and the standard subnet size, > I'd say that the probabilities are (or could be engineered to be) on > the side of non-reuse. Yup. Sounds like stateless addrconf. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Sep 27 22:17:53 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27478; Wed, 27 Sep 2000 22:17:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8S299b15085; Wed, 27 Sep 2000 22:09:17 -0400 (EDT) Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8S28tb25975 for ; Wed, 27 Sep 2000 22:08:55 -0400 (EDT) Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345) id A5090327C; Wed, 27 Sep 2000 21:08:39 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 22840310A for ; Wed, 27 Sep 2000 21:08:39 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id WAA0000595707; Wed, 27 Sep 2000 22:08:31 -0400 (EDT) From: Jim Bound Message-Id: <200009280208.WAA0000595707@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-reply-to: Your message of "Tue, 26 Sep 2000 06:16:44 EDT." <200009261016.GAA02068@hygro.adsl.duke.edu> Date: Wed, 27 Sep 2000 22:08:30 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi Thomas, >> Its also in 11.4.2 section under Request Retransmit. The current specs >> version of an IA is the link-local address + prefix for that link. The >> client does not try to renew the IA as the concept is new from our >> design discussions. The spec was written with the intention that >> link-local and prefix of link will be unique and it is in IPv6, except >> when a node changes its link-local now because of privacy concerns and >> uses anonymous addresses. >To clarify, in the current version of anonymous addresses >(draft-ietf-ipngwg-addrconf-privacy-03.txt) link-local (and >site-local) addresses do not change and are not made anonymous. Only >global addresses are subject to being anonymized. Great. I just assumed the EUID got trashed. Bad assumption. Glad you caught that. That means we can still use the link-local address if we want as described in DHCPv6 as potentially part of the IA or at least keep in the discussion. thanks /jim From owner-dhcp-v6@bucknell.edu Wed Sep 27 23:57:44 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29836; Wed, 27 Sep 2000 23:57:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8S3t3b00941; Wed, 27 Sep 2000 23:55:03 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8S3skb03489 for ; Wed, 27 Sep 2000 23:54:47 -0400 (EDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA05446 for ; Wed, 27 Sep 2000 20:54:45 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id UAA20589 for ; Wed, 27 Sep 2000 20:54:45 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8S3she398022 for ; Wed, 27 Sep 2000 20:54:43 -0700 (PDT) Date: Wed, 27 Sep 2000 20:54:37 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DHCPv6 address model proposal... To: DHCPv6 discussion list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph, > My thought was that specifying that the server send a complete list of only > the client's currently valid addresses was actually a simplification - the > client can simply throw out its old list of addresses and copy down the > current list from the server. > > However, there is a second step - the client has to update the > configuration of its interfaces with the list of addresses from the > server. So, I imagine simply omitting addresses makes the client's job a > little harder - it has to poke around at each of the interfaces and see if > any of the addresses on those interfaces were missing from the message and > must therefore be un-configured. Agreed. This is made a bit tricker by the fact that it should be possible to use both stateless and DHCPv6 to configure addresses on a host at the same time (section 4 in RFC 2462). Thus the client should not touch any IP addresses that were configured through the stateful mechanism when doing the above un-configuration. Erik > But, as Ted points out, requiring the server to specifically invalidate > addresses may make the server implementation more complex - the server will > have to remember each client's previous list of assigned addresses as well > as any newly assigned addresses until the client has renewed its IA. > > - Ralph > From owner-dhcp-v6@bucknell.edu Thu Sep 28 14:33:58 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29083; Thu, 28 Sep 2000 14:33:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8SITkb19643; Thu, 28 Sep 2000 14:29:46 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8SITbb13639 for ; Thu, 28 Sep 2000 14:29:37 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-248.rc.vix.com [204.152.187.248]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id HAA22000 for ; Wed, 27 Sep 2000 07:54:04 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8SIPfE00938 for ; Thu, 28 Sep 2000 11:25:42 -0700 (MST) Message-Id: <200009281825.e8SIPfE00938@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Jim Bound of "Wed, 27 Sep 2000 22:08:30 -0400." <200009280208.WAA0000595707@anw.zk3.dec.com> Date: Thu, 28 Sep 2000 11:25:41 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > That means we can still use the link-local address if we want as > described in DHCPv6 as potentially part of the IA or at least keep in > the discussion. The link-local address changes when you swap network cards. It is stable with respect to a piece of peripheral hardware, not with respect to an actual client machine. For this reason, I am not at all enthusiastic about the idea of using it as a client identifier. If we don't strongly discourage its use, I am afraid that we will run into the same old set of problems we had with DHCPv4 with respect to client identifiers being tied to hardware. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Sep 28 15:39:01 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00461; Thu, 28 Sep 2000 15:39:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8SJa6b24676; Thu, 28 Sep 2000 15:36:06 -0400 (EDT) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8SJa2b10869 for ; Thu, 28 Sep 2000 15:36:02 -0400 (EDT) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id E50AC2039; Thu, 28 Sep 2000 14:35:46 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 7FD961150 for ; Thu, 28 Sep 2000 14:35:46 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id PAA0000694326; Thu, 28 Sep 2000 15:35:13 -0400 (EDT) From: Jim Bound Message-Id: <200009281935.PAA0000694326@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-reply-to: Your message of "Thu, 28 Sep 2000 11:25:41 PDT." <200009281825.e8SIPfE00938@grosse.bisbee.fugue.com> Date: Thu, 28 Sep 2000 15:35:13 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >> That means we can still use the link-local address if we want as >> described in DHCPv6 as potentially part of the IA or at least keep in >> the discussion. >The link-local address changes when you swap network cards. It is >stable with respect to a piece of peripheral hardware, not with >respect to an actual client machine. For this reason, I am not at >all enthusiastic about the idea of using it as a client identifier. >If we don't strongly discourage its use, I am afraid that we will run >into the same old set of problems we had with DHCPv4 with respect to >client identifiers being tied to hardware. I hear what your saying. But I will use an argument you use often I think? How many clients of a 1000 node installation will change their ethernet card within 6 months at Boeing? Or at MIT? I would say not most. We are using the link-local address for all kinds of stuff now in IPv6 too. But how about this strategy. We clearly are going to change in the packets to having some IA identifier. What we can do is permit the link-local address with the health warning you state above and have other options too. But here is other idea for the IA to think about. Organizations can request a OUI (24bits) and we can then begin to add to that. I believe Multicast uses this now. regards, /jim From owner-dhcp-v6@bucknell.edu Thu Sep 28 16:06:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01042; Thu, 28 Sep 2000 16:06:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8SK6Pb10178; Thu, 28 Sep 2000 16:06:25 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8SK6Bb07029 for ; Thu, 28 Sep 2000 16:06:11 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Sep 2000 16:05:55 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC1D5@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: DHCPv6 address model proposal... Date: Thu, 28 Sep 2000 16:05:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm with Ted on this one ... I think it best to attempt to generate a unqiue client id by not using the link-local or MAC address. At least, the unique client id should not just be this with a few prefix bytes. However, having said that, I have no problem in a client generating (with some random component) a unique client identifier from the MAC address (or link-local addresses) it may have and saving that in stable storage such that it would use that in the future, regardless of whether one or more interfaces is changed. - Bernie -----Original Message----- From: Jim Bound [mailto:bound@zk3.dec.com] Sent: Thursday, September 28, 2000 3:35 PM To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... >> That means we can still use the link-local address if we want as >> described in DHCPv6 as potentially part of the IA or at least keep in >> the discussion. >The link-local address changes when you swap network cards. It is >stable with respect to a piece of peripheral hardware, not with >respect to an actual client machine. For this reason, I am not at >all enthusiastic about the idea of using it as a client identifier. >If we don't strongly discourage its use, I am afraid that we will run >into the same old set of problems we had with DHCPv4 with respect to >client identifiers being tied to hardware. I hear what your saying. But I will use an argument you use often I think? How many clients of a 1000 node installation will change their ethernet card within 6 months at Boeing? Or at MIT? I would say not most. We are using the link-local address for all kinds of stuff now in IPv6 too. But how about this strategy. We clearly are going to change in the packets to having some IA identifier. What we can do is permit the link-local address with the health warning you state above and have other options too. But here is other idea for the IA to think about. Organizations can request a OUI (24bits) and we can then begin to add to that. I believe Multicast uses this now. regards, /jim From owner-dhcp-v6@bucknell.edu Thu Sep 28 18:17:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03846; Thu, 28 Sep 2000 18:17:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8SMEWb28355; Thu, 28 Sep 2000 18:14:32 -0400 (EDT) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8SMELb02460 for ; Thu, 28 Sep 2000 18:14:22 -0400 (EDT) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 9762626DA; Thu, 28 Sep 2000 18:14:06 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 72A163301 for ; Thu, 28 Sep 2000 18:14:06 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id SAA0000633699; Thu, 28 Sep 2000 18:13:31 -0400 (EDT) From: Jim Bound Message-Id: <200009282213.SAA0000633699@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: bound@ZK3.DEC.COM Subject: Re: DHCPv6 address model proposal... In-reply-to: Your message of "Thu, 28 Sep 2000 16:05:54 EDT." <63D30D6E10CFD11190A90000F805FE8602BEC1D5@lespaul.process.com> Date: Thu, 28 Sep 2000 18:13:30 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I am with you and ted too. but what I am concerned about is getting a spec solution out by december too. not pushing the link-local address but as example. for the link-local the dhcp server can trust it is unique on a link and the prefix is unique on a link. no chance of duplication because of DAD and address architecture in IPv6. How do we verify that a clients IA is in fact unique if it don't verify that with other clients? a) on the link best case b) with the servers dhcp domain? Also what is the range that the IA is unique? 1) link 2) site 3) global (I doubt we can figure that out in dhc) We need to state how far the IA is unique for a dhcp server In the current spec that is known. That is why I brought up the OUI to Ted ???? /jim From owner-dhcp-v6@bucknell.edu Thu Sep 28 20:28:54 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05957; Thu, 28 Sep 2000 20:28:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8T0QGb27880; Thu, 28 Sep 2000 20:26:17 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8T0QEb27230 for ; Thu, 28 Sep 2000 20:26:15 -0400 (EDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA22806 for ; Thu, 28 Sep 2000 17:26:13 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id RAA27832 for ; Thu, 28 Sep 2000 17:26:13 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.1+Sun/8.11.1.Beta1) with SMTP id e8T0QC5545773 for ; Thu, 28 Sep 2000 17:26:12 -0700 (PDT) Date: Thu, 28 Sep 2000 17:26:05 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DHCPv6 address model proposal... To: DHCPv6 discussion list In-Reply-To: "Your message with ID" <200009252238.e8PMcep06075@grosse.bisbee.fugue.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted, > No. REBIND is when the client has already tried to renew the lease by > contacting the server from which it got the lease using a unicast > message. Time is running out, so it decides to see if it can contact > another server using multicast (broadcast in the DHCPv4 case). > REBINDING and RENEWING are two distinct states, and REBINDING is > specifically for cases where the old server can't be contacted. > > I do not think it is necessary for the client to send an address list > in the RENEWING case - only in the REBINDING case. I agree for the purposes that has been currently discussed. But not too long back we discussed whether the omission of an address from an IAS when renewing was to be interpreted as "invalidate any other address not returned by the server". I might be wrong but I think I saw concensus not to treat a "missing" address as a directive for the client to invalidate it. Assuming I didn't miss anything, we have two choices dealing with the server removing addresses/prefixes from use (apart from explicit reconfigure of course): - the server retains state of all addresses handed to the client and when one address is removed from the set the server hands that back to the client with valid lifetime = 0 when the client renews. For reliability the server might need to retain information about the invalidated address for some time since the client might not receive the first reply that has lifetime = 0. - require that the client include all addresses when renewing. if the server see one address that shouldn't be part of the set the reply will include that address with lifetime = 0. Nothing special needs to be done to get reliability here. I might have missed this being discussed in the past. Erik From owner-dhcp-v6@bucknell.edu Thu Sep 28 21:49:56 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07575; Thu, 28 Sep 2000 21:49:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8T1kkb29240; Thu, 28 Sep 2000 21:46:46 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8T1kjb19199 for ; Thu, 28 Sep 2000 21:46:45 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Sep 2000 21:46:29 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC1DA@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: DHCPv6 address model proposal... Date: Thu, 28 Sep 2000 21:46:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > - the server retains state of all addresses handed to the client > and when one address is removed from the set the server > hands that back to the client with valid lifetime = 0 > when the client renews. For reliability the server might need to > retain information about the invalidated address for some time > since the client might not receive the first reply that has lifetime = 0. The server need not do this. The server can simply eliminate the address from the client's set. The client can continue to use that address until the lifetimes "expire" - just because it isn't in the server's response does not mean that the address has expired. Of course, you are correct if the server wants to immediately remove the address from the client's set. While I do understand the desire to reduce packet sizes and avoid unnecessary data in packets, I am a bit uncomfortable with not having the client supply the addresses. We have discussed this and I agree that in almost all cases it isn't explicitly necessary. But it is a major shift from what happens today in DHCPv4 and I just fear it may be a mistake. I also think it benefits the server since it too can know what the client knows. -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@ENG.SUN.COM] Sent: Thursday, September 28, 2000 8:26 PM To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... Ted, > No. REBIND is when the client has already tried to renew the lease by > contacting the server from which it got the lease using a unicast > message. Time is running out, so it decides to see if it can contact > another server using multicast (broadcast in the DHCPv4 case). > REBINDING and RENEWING are two distinct states, and REBINDING is > specifically for cases where the old server can't be contacted. > > I do not think it is necessary for the client to send an address list > in the RENEWING case - only in the REBINDING case. I agree for the purposes that has been currently discussed. But not too long back we discussed whether the omission of an address from an IAS when renewing was to be interpreted as "invalidate any other address not returned by the server". I might be wrong but I think I saw concensus not to treat a "missing" address as a directive for the client to invalidate it. Assuming I didn't miss anything, we have two choices dealing with the server removing addresses/prefixes from use (apart from explicit reconfigure of course): - the server retains state of all addresses handed to the client and when one address is removed from the set the server hands that back to the client with valid lifetime = 0 when the client renews. For reliability the server might need to retain information about the invalidated address for some time since the client might not receive the first reply that has lifetime = 0. - require that the client include all addresses when renewing. if the server see one address that shouldn't be part of the set the reply will include that address with lifetime = 0. Nothing special needs to be done to get reliability here. I might have missed this being discussed in the past. Erik From owner-dhcp-v6@bucknell.edu Fri Sep 29 06:30:47 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25936; Fri, 29 Sep 2000 06:30:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8TASAb04959; Fri, 29 Sep 2000 06:28:10 -0400 (EDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8TAS9b00155 for ; Fri, 29 Sep 2000 06:28:09 -0400 (EDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel1.hp.com (Postfix) with ESMTP id 69178120B for ; Fri, 29 Sep 2000 03:28:06 -0700 (PDT) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by hpuxsrv.india.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id PAA12947 for ; Fri, 29 Sep 2000 15:57:00 +0530 (IST) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <39D46F37.DCFFCFDB@dce.india.hp.com> Date: Fri, 29 Sep 2000 16:00:17 +0530 From: vijaya bhaskar Organization: hp ISO X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.10 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: IP Address Reconfiguration Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu X-Sender: vijayak@india.hp.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello, I'm working on dhcp for hp ISO. In the Internet draft, it is told that releasable resources like ip address can be reconfigured using Reconfigure-init followed by Request/Reply . In case, if the ip address for an particular interface is reconfigured, what will happen to the existing application running on that ip address. Is these application needed to be restarted ? waiting for your reply. Regards, Vijay. From owner-dhcp-v6@bucknell.edu Fri Sep 29 12:38:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02634; Fri, 29 Sep 2000 12:38:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8TGZlb06740; Fri, 29 Sep 2000 12:35:47 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8TGZeb09143 for ; Fri, 29 Sep 2000 12:35:40 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA00469 for ; Fri, 29 Sep 2000 09:35:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e8TGZMG12226 for ; Fri, 29 Sep 2000 09:35:22 -0700 X-Virus-Scanned: Fri, 29 Sep 2000 09:35:22 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdLQMDcD; Fri, 29 Sep 2000 09:35:18 PDT Sender: owner-dhcp-v6@bucknell.edu Message-ID: <39D4C4C7.FFC1D5AC@iprg.nokia.com> Date: Fri, 29 Sep 2000 09:35:19 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: Re: IP Address Reconfiguration References: <39D46F37.DCFFCFDB@dce.india.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu X-Sender: charliep@iprg.nokia.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello Vijay, The reconfiguration you refer to was designed for network renumbering and network administrative purposes. Any network renumbering would, presumably, be spread over long enough time so that applications would be able to complete their work before the expiration of the lifetime for their original IP addresses. Of course, you can always make an application that needs to run for weeks or months and would thus violate this design criterion, but the hope is that the overall number of such applications will be vanishingly small. Regards, Charlie P. vijaya bhaskar wrote: > > Hello, > > I'm working on dhcp for hp ISO. > > In the Internet draft, it is told that releasable resources like ip > address can be reconfigured using Reconfigure-init followed by > Request/Reply . In case, if the ip address for an particular interface > is reconfigured, what will happen to the existing application running on > that ip address. Is these application needed to be restarted ? > > waiting for your reply. > > Regards, > Vijay. From owner-dhcp-v6@bucknell.edu Fri Sep 29 14:43:24 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05053; Fri, 29 Sep 2000 14:43:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8TIegb27664; Fri, 29 Sep 2000 14:40:42 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8TIeRb11760 for ; Fri, 29 Sep 2000 14:40:28 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-235.rc.vix.com [204.152.187.235]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id IAA26763; Thu, 28 Sep 2000 08:04:51 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8T1ra900266; Thu, 28 Sep 2000 18:53:36 -0700 (MST) Message-Id: <200009290153.e8T1ra900266@grosse.bisbee.fugue.com> To: DHCPv6 discussion list cc: bound@ZK3.DEC.COM Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Jim Bound of "Thu, 28 Sep 2000 18:13:30 -0400." <200009282213.SAA0000633699@anw.zk3.dec.com> Date: Thu, 28 Sep 2000 18:53:35 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > How do we verify that a clients IA is in fact unique if it don't verify > that with other clients? > a) on the link best case > b) with the servers dhcp domain? The schemes that have been proposed for coming up with UUIDs (Universally Unique Identifiers) rely more on reducing the chance of collision to ridiculously low amounts than they do on any mechanical process of guaranteeing that the identifier is unique. I am pretty sure that Windows has a UUID that is generated this way. Computers with serial numbers could use a vendor name plus the serial number. I think the language in the draft should say something like "DHCP clients SHOULD use a client identifier that will not vary as a result of changes in network hardware and will be consistent between network interfaces. DHCP clients SHOULD NOT use the link-layer address of a network interface by itself as a client identifier, but SHOULD instead use some other identifier that is known to be globally unique - for example, a combination of the CPU's serial number and manufacturer's registered domain name. DHCP clients that have no unique identifier other than the link-layer address SHOULD combine the link-layer address of one or more network interfaces, padded with zeros at the end to a total length of sixteen bytes, with a randomly-generated four-byte quantity, and compute an MD5 (SHA?) hash over this to produce a unique identifier, and should store this identifier in stable storage. Clients that have no stable storage MUST use the link-layer address of one of their network interfaces as the client identifer, and MUST use the same client identifier for all of their interfaces." This is rather convoluted, but I think it covers all the possible cases where one could get into trouble. The only case where we could get into trouble is if two clients connected to the same link use the HASH (pad16 (link-layer-addr) + random4) and wind up producing the same hash value. The reason for using the highly-structured formula for producing the hash is to make this vanishingly unlikely, but I'm not a crypto-geek, so I may have gotten it wrong. We could also require the client to identify which of the algorithms it is using in the first byte of the identifier, which would avoid stupid collisions due to differing algorithms. The language should also probably be made more readable - I'd be happy to do this if people think this is a good set of methods to use to generate the client identifier. BTW, I am just talking about how to generate the common per-client part of the identifier. We also talked about the client combining its per-client identifier with an additional per-instance identifier so as to uniquely identify an address association, so that the client could have more than one address association - e.g., for application- specific situations or for clients supporting more than one interface, or using DHCP to manage a care-of address as well as a home address. _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Sep 29 14:47:51 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05115; Fri, 29 Sep 2000 14:47:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8TIl7b29974; Fri, 29 Sep 2000 14:47:07 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8TIl2b13236 for ; Fri, 29 Sep 2000 14:47:02 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-235.rc.vix.com [204.152.187.235]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id IAA26782; Thu, 28 Sep 2000 08:11:28 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8TIkq601541; Fri, 29 Sep 2000 11:46:52 -0700 (MST) Message-Id: <200009291846.e8TIkq601541@grosse.bisbee.fugue.com> To: DHCPv6 discussion list cc: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Erik Nordmark of "Thu, 28 Sep 2000 17:26:05 MST." Date: Fri, 29 Sep 2000 11:46:52 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Assuming I didn't miss anything, we have two choices dealing > with the server removing addresses/prefixes from use > (apart from explicit reconfigure of course): > - the server retains state of all addresses handed to the client > and when one address is removed from the set the server > hands that back to the client with valid lifetime = 0 > when the client renews. For reliability the server might need to > retain information about the invalidated address for some time > since the client might not receive the first reply that has lifetime = 0. > > - require that the client include all addresses when renewing. > if the server see one address that shouldn't be part of the set > the reply will include that address with lifetime = 0. > Nothing special needs to be done to get reliability here. I think this is a valid summary, and your list of choices is correct. I think given that the fact of the client receiving an IA that doesn't contain a still-valid address does not invalidate the address, we have to do the first of your two choices. This is why I was arguing against this. But I think the reason for doing it this way is stronger than the reason for doing it the other way, so I'm not arguing that point anymore. _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Sep 29 14:50:39 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05146; Fri, 29 Sep 2000 14:50:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8TInub26940; Fri, 29 Sep 2000 14:49:56 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8TInqb19826 for ; Fri, 29 Sep 2000 14:49:52 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-235.rc.vix.com [204.152.187.235]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id IAA26803 for ; Thu, 28 Sep 2000 08:14:18 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8TIng601609 for ; Fri, 29 Sep 2000 11:49:42 -0700 (MST) Message-Id: <200009291849.e8TIng601609@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPv6 address model proposal... In-Reply-To: Message from Bernie Volz of "Thu, 28 Sep 2000 21:46:29 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC1DA@lespaul.process.com> Date: Fri, 29 Sep 2000 11:49:42 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > While I do understand the desire to reduce packet sizes and avoid > unnecessary data in packets, I am a bit uncomfortable with not having the > client supply the addresses. We have discussed this and I agree that in > almost all cases it isn't explicitly necessary. But it is a major shift from > what happens today in DHCPv4 and I just fear it may be a mistake. I also > think it benefits the server since it too can know what the client knows. Only if we make it mandatory that the client send this. I don't think we should. We are saying that the client should send this information when it's in the (currently nonexistant) REBINDING state. However, if we only send it in that state we get a substantial space savings - clients should never *get* into that state normally. So I think it's worth it. I think you should have a strong reason to argue otherwise. _MelloN_