Received: from cnri by ietf.org id aa23048; 3 Feb 97 23:16 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa00445; 3 Feb 97 23:16 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA25196; Mon, 3 Feb 1997 23:13:36 -0500 Date: Mon, 3 Feb 1997 23:13:36 -0500 Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Munil Shah To: Multiple recipients of list Subject: DHCPNAK and multiple logical subnet issue X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Hi All, Here's the setup. I have multiple logical subnets A and B on same physical net. DHCP client gets an IP address from DHCPServer-A. On the next reboot, it broadcasts DHCPREQUEST. Server A gets it and sends an DHCPACK. Server B also gets the same request and sends a DHCPNAK as per draft-ietf-dhc-dhcp-09.txt, section 4.3.2, topic DHCPREQUEST generated during INIT-REBOOT state. The client happens to get the DHCPNAK first and that forces him to get a new IP address even though its lease for the previous IP address is still valid. This in turn causes DNS and NBNS entries for this client to get updated and extra network traffic. How do I fix this? There are several issues/suggestions. 1) If I make server B ignore the request then a new client which has just moved to its net will continue to use invalid address(i.e one that does not belong to this new net). This will be a violation of the RFC. 2) May be I should NAK only if 'secs' field is non-zero. This way on the first broadcast of DHCPREQUEST, only A responds with ACK preventing B from sending NAK. But what if A does not get the first broadcast? Or what if A is down? In both cases B WILL send NAK during second retransmit, forcing client to get a new IP address. 3) May be client should do a subnet broadcast of DHCPREQUEST. This way only A will get the DHCPREQUEST. But what if A is down? In this case, do we revert back to all FF broadcasts(which would result in B sending DHCPNAK) OR we continue to use the old IP address( which may result in it keeping an invalid ip address, if we had just moved to the new net). Any thoughts? Thanks, -Munil Shah Software Design Engineer, Microsoft Corp.   Received: from cnri by ietf.org id aa07580; 4 Feb 97 10:25 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa13503; 4 Feb 97 10:25 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA27380; Tue, 4 Feb 1997 10:22:48 -0500 Date: Tue, 4 Feb 1997 10:22:48 -0500 Message-Id: <199702041433.JAA15266@hotsprings.american.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: DHCPNAK and multiple logical subnet issue X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Hi All, > Here's the setup. I have multiple logical subnets A and B on same > physical net. DHCP client gets an IP address from DHCPServer-A. On the > next reboot, it broadcasts DHCPREQUEST. Server A gets it and sends an > DHCPACK. Server B also gets the same request and sends a DHCPNAK as per > draft-ietf-dhc-dhcp-09.txt, section 4.3.2, topic DHCPREQUEST generated > during INIT-REBOOT state. The client happens to get the DHCPNAK first > and that forces him to get a new IP address even though its lease for > the previous IP address is still valid. This in turn causes DNS and NBNS > entries for this client to get updated and extra network traffic. > > How do I fix this? There are several issues/suggestions. [...] > > Any thoughts? > > Thanks, > -Munil Shah > Software Design Engineer, > Microsoft Corp. This is an interesting issue, related to one from a few weeks ago (at least in my mind). I'm a bit confused by your setup. It sounds like you have multiple logical subnets (A and B) on the same wire, and two servers on that wire as well -- one serving subnet A and one serving subnet B. Each server knows only about its own subnet -- but receives broadcasts from all clients on the wire. True? If this is true, then each server will always see INIT-REBOOT's from clients of the other server as "on the wrong network". We do not recommend such a configuration to our customers. We tell them to configure each DHCP server on the wire with information about *both* subnet A and B precisely so that the servers will handle this situation gracefully and not get into "one-NAK-man-ship" with clients of the other server. I believe such support is widely known as secondary subnet support. Perhaps I'm mistaken in my assumptions about your configuration. It might help if you could explain it a bit more in detail. Cheers -- Kim Kim Kinnear American Internet Corp.   Received: from cnri by ietf.org id aa07605; 4 Feb 97 10:26 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa13536; 4 Feb 97 10:26 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA05681; Tue, 4 Feb 1997 10:23:58 -0500 Date: Tue, 4 Feb 1997 10:23:58 -0500 Message-Id: <32F74F29.23D@chevron.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Michael J. Lewis" To: Multiple recipients of list Subject: Re: DHCPNAK and multiple logical subnet issue X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Mime-Version: 1.0 X-Mailer: Mozilla 3.0 (Win95; I) This is solved within the server implementation. I'm not sure whether you are asking how to do this within a server implementation or which servers provide this feature. In the latter category, virtually all of the recently introduced servers provide support for multiple subnets on the same wire including Microsoft which introduced this support via the superscope feature in Service Pack 2 for Windows NT 4.0. Others like Competitive Automation, American Internet, Cisco, ... have this support as well. Munil Shah wrote: > > Hi All, > Here's the setup. I have multiple logical subnets A and B on same > physical net. DHCP client gets an IP address from DHCPServer-A. On the > next reboot, it broadcasts DHCPREQUEST. Server A gets it and sends an > DHCPACK. Server B also gets the same request and sends a DHCPNAK as per > draft-ietf-dhc-dhcp-09.txt, section 4.3.2, topic DHCPREQUEST generated > during INIT-REBOOT state. The client happens to get the DHCPNAK first > and that forces him to get a new IP address even though its lease for > the previous IP address is still valid. This in turn causes DNS and NBNS > entries for this client to get updated and extra network traffic. > > How do I fix this? There are several issues/suggestions. > > 1) If I make server B ignore the request then a new client which has > just moved to its net will continue to use invalid address(i.e one that > does not belong to this new net). This will be a violation of the RFC. > 2) May be I should NAK only if 'secs' field is non-zero. This way on the > first broadcast of DHCPREQUEST, only A responds with ACK preventing B > from sending NAK. But what if A does not get the first broadcast? Or > what if A is down? In both cases B WILL send NAK during second > retransmit, forcing client to get a new IP address. > 3) May be client should do a subnet broadcast of DHCPREQUEST. This way > only A will get the DHCPREQUEST. But what if A is down? In this case, do > we revert back to all FF broadcasts(which would result in B sending > DHCPNAK) OR we continue to use the old IP address( which may result in > it keeping an invalid ip address, if we had just moved to the new net). > > Any thoughts? > > Thanks, > -Munil Shah > Software Design Engineer, > Microsoft Corp.   Received: from cnri by ietf.org id aa19439; 4 Feb 97 13:09 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa18180; 4 Feb 97 13:09 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA17485; Tue, 4 Feb 1997 13:06:47 -0500 Date: Tue, 4 Feb 1997 13:06:47 -0500 Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Munil Shah To: Multiple recipients of list Subject: RE: DHCPNAK and multiple logical subnet issue X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 see below: >-----Original Message----- >From: Kim Kinnear [SMTP:kinnear@american.com] >Sent: Tuesday, February 04, 1997 7:22 AM >To: Multiple recipients of list >Subject: Re: DHCPNAK and multiple logical subnet issue > > > > >> Hi All, >> Here's the setup. I have multiple logical subnets A and B on same >> physical net. DHCP client gets an IP address from DHCPServer-A. On the >> next reboot, it broadcasts DHCPREQUEST. Server A gets it and sends an >> DHCPACK. Server B also gets the same request and sends a DHCPNAK as per >> draft-ietf-dhc-dhcp-09.txt, section 4.3.2, topic DHCPREQUEST generated >> during INIT-REBOOT state. The client happens to get the DHCPNAK first >> and that forces him to get a new IP address even though its lease for >> the previous IP address is still valid. This in turn causes DNS and NBNS >> entries for this client to get updated and extra network traffic. >> >> How do I fix this? There are several issues/suggestions. >[...] >> >> Any thoughts? >> >> Thanks, >> -Munil Shah >> Software Design Engineer, >> Microsoft Corp. > >This is an interesting issue, related to one from a few weeks ago (at >least in my mind). > >I'm a bit confused by your setup. It sounds like you have multiple >logical subnets (A and B) on the same wire, and two servers on that >wire as well -- one serving subnet A and one serving subnet B. Each >server knows only about its own subnet -- but receives broadcasts from >all clients on the wire. True? > >[MunilS] TRUE! > >If this is true, then each server will always see INIT-REBOOT's from >clients of the other server as "on the wrong network". We do not >recommend such a configuration to our customers. > >We tell them to configure each DHCP server on the wire with information >about *both* subnet A and B precisely so that the servers will handle >this situation gracefully and not get into "one-NAK-man-ship" with >clients of the other server. I believe such support is widely known as >secondary subnet support. > >[MunilS] We dont recommend such setup either. But for historic reasons, our >clients have such setup and they want us to find a solution to this. > >Perhaps I'm mistaken in my assumptions about your configuration. It >might help if you could explain it a bit more in detail. > >Cheers -- Kim > >Kim Kinnear >American Internet Corp.   Received: from cnri by ietf.org id aa15195; 6 Feb 97 20:01 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa29980; 6 Feb 97 20:01 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA22942; Thu, 6 Feb 1997 19:58:08 -0500 Date: Thu, 6 Feb 1997 19:58:08 -0500 Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "James, Warren A (wajames)" To: Multiple recipients of list Subject: RE: DHCPNAK and multiple logical subnet issue X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Mime-Version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.13 The scenario where this feature bit us was with an NT4.0SP2 DHCP server that had "reservations" for two clients and our legacy DHCP setup: Our DHCP setup is an outgrowth of our BOOTP setup. We have static mapped IP addresses for 20K+ PC's (we originally used BOOTP and updated the BOOTP server to use the DHCP protocol). All the IP addresses are "reservation" based, and the DHCP server is almost always on a remote network from the Clients (all 20K+ clients are serviced by 4 DHCP servers - one each in 4 regional data centers - each has a copy of an identical DHCP reservation database). Given this legacy DCHP setup and a "local" NT4.0/SP2 DHCP server (set up by a local admin who had no understanding of the multiple IP subnets on the large switched ethernet LAN to which his NT server was connected and so was unable to "properly" configure the Superscope and further who was unaware of the new feature in SP2 to even begin to ask the question - whew), the local NT DHCP gave every DHCP client not on the same subnet as itself a DHCPNAK and the clients then failed to boot ... even when the NT DHCP server had only two ip addresses in it's "scope" and both of those were reserved for other machines. I'd concede that fact that a "properly" configured Superscoping DHCP server _should_ NAK a client broadcasting a "wrong subnet" request, but in our network - all DHCP servers are required to be reservation based to avoid creating problems with the clients of the DHCP central servers. So our perspective is that a Superscoping DHCP server with "reservations" only, should not NAK any clients but it's "own". BTW We are looking to modify the central DHCP servers to also provide dynamic addressing, but we would still have the requirement for "local" DHCP servers to be reservation based. -- Warren James Pacific * Bell Principal Network Analyst wajames@PacBell.COM >---------- >From: Munil Shah[SMTP:munils@MICROSOFT.com] >Sent: Tuesday, February 04, 1997 10:08 AM >To: Multiple recipients of list >Subject: RE: DHCPNAK and multiple logical subnet issue > >Yes, NT4.0SP2 has this support for superscope. But the clients already >have the old setup and they want backward compatibility. > >>-----Original Message----- >>From: Michael J. Lewis [SMTP:hosmjl@chevron.com] >>Sent: Tuesday, February 04, 1997 7:24 AM >>To: Multiple recipients of list >>Subject: Re: DHCPNAK and multiple logical subnet issue >> >>This is solved within the server implementation. I'm not sure whether >>you are asking how to do this within a server implementation or which >>servers provide this feature. In the latter category, virtually all of >>the recently introduced servers provide support for multiple subnets on >>the same wire including Microsoft which introduced this support via the >>superscope feature in Service Pack 2 for Windows NT 4.0. Others like >>Competitive Automation, American Internet, Cisco, ... have this support >>as well. >> >>Munil Shah wrote: >>> >>> Hi All, >>> Here's the setup. I have multiple logical subnets A and B on same >>> physical net. DHCP client gets an IP address from DHCPServer-A. On the >>> next reboot, it broadcasts DHCPREQUEST. Server A gets it and sends an >>> DHCPACK. Server B also gets the same request and sends a DHCPNAK as per >>> draft-ietf-dhc-dhcp-09.txt, section 4.3.2, topic DHCPREQUEST generated >>> during INIT-REBOOT state. The client happens to get the DHCPNAK first >>> and that forces him to get a new IP address even though its lease for >>> the previous IP address is still valid. This in turn causes DNS and NBNS >>> entries for this client to get updated and extra network traffic. >>> >>> How do I fix this? There are several issues/suggestions. >>> >>> 1) If I make server B ignore the request then a new client which has >>> just moved to its net will continue to use invalid address(i.e one that >>> does not belong to this new net). This will be a violation of the RFC. >>> 2) May be I should NAK only if 'secs' field is non-zero. This way on the >>> first broadcast of DHCPREQUEST, only A responds with ACK preventing B >>> from sending NAK. But what if A does not get the first broadcast? Or >>> what if A is down? In both cases B WILL send NAK during second >>> retransmit, forcing client to get a new IP address. >>> 3) May be client should do a subnet broadcast of DHCPREQUEST. This way >>> only A will get the DHCPREQUEST. But what if A is down? In this case, do >>> we revert back to all FF broadcasts(which would result in B sending >>> DHCPNAK) OR we continue to use the old IP address( which may result in >>> it keeping an invalid ip address, if we had just moved to the new net). >>> >>> Any thoughts? >>> >>> Thanks, >>> -Munil Shah >>> Software Design Engineer, >>> Microsoft Corp. >   Received: from cnri by ietf.org id aa02444; 7 Feb 97 18:01 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa25505; 7 Feb 97 18:01 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB13932; Fri, 7 Feb 1997 17:58:48 -0500 Date: Fri, 7 Feb 1997 17:58:48 -0500 Message-Id: <199702052317.RAA07774@zoo. zoo.ou.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Jeff Taylor Taylor"@zoo, eff@mail.bucknell.edu MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US To: Multiple recipients of list Subject: WIN/95 Init State X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Pegasus Mail for Win32 (v2.52) Mime-Version: 1.0 All, I am noticing a problem with WIN/95. What determines that a client is supposed to do a DHCPDISCOVER & not a DHCPREQUEST I have noticed the problem when a client is given an address that is in conflict for some reason. Even though the address is removed from the pool of available addresses on the server, the client still requests the old address. How can you clear that address out of the client, so that it will do a DHCPDISCOVER? Jeff Taylor jefft@ou.edu Network Specialist Telecommunications Dept. University of Oklahoma   Received: from cnri by ietf.org id aa02503; 7 Feb 97 18:02 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa25529; 7 Feb 97 18:02 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AC13830; Fri, 7 Feb 1997 18:00:28 -0500 Date: Fri, 7 Feb 1997 18:00:28 -0500 Message-Id: <199702052317.RAA07776@zoo. zoo.ou.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Jeff Taylor Taylor"@zoo, eff@mail.bucknell.edu MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US To: Multiple recipients of list Subject: WIN/95 Init State X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Pegasus Mail for Win32 (v2.52) Mime-Version: 1.0 All, I am noticing a problem with WIN/95. What determines that a client is supposed to do a DHCPDISCOVER & not a DHCPREQUEST I have noticed the problem when a client is given an address that is in conflict for some reason. Even though the address is removed from the pool of available addresses on the server, the client still requests the old address. How can you clear that address out of the client, so that it will do a DHCPDISCOVER? Jeff Taylor jefft@ou.edu Network Specialist Telecommunications Dept. University of Oklahoma   Received: from cnri by ietf.org id aa21718; 10 Feb 97 10:40 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa12173; 10 Feb 97 10:40 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB18373; Mon, 10 Feb 1997 10:29:18 -0500 Date: Mon, 10 Feb 1997 10:29:18 -0500 Message-Id: <9701108556.AA855614401@pcmaileu.euro.ml.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Daran_Rowlands@pcmaileu.euro.ml.com To: Multiple recipients of list Subject: Re: Question about Wins and bootp-DD2.4.3 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Hi, Anyone got an answer to this yet?... cheers, Daran. ______________________________ Reply Separator _________________________________ Subject: Question about Wins and bootp-DD2.4.3 Author: dhcp-v4@bucknell.edu at UNIXGTWY Date: 20/01/97 09:11 Hi, has anyone made any modifications to the CMU bootp-DD2.4.3 code to enable it to pass two Wins-server addresses to a client? If so, could you possibly post the necessary patches to me? thanks in advance, Daran Rowlands Senior Network Analyst Merrill Lynch Europe PLC daran_rowlands@ml.com   Received: from cnri by ietf.org id aa28728; 10 Feb 97 13:14 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa17333; 10 Feb 97 13:14 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AC14293; Mon, 10 Feb 1997 12:59:10 -0500 Date: Mon, 10 Feb 1997 12:59:10 -0500 Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Erikas Aras Napjus To: Multiple recipients of list Subject: Re: Question about Wins and bootp-DD2.4.3 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > has anyone made any modifications to the CMU bootp-DD2.4.3 code to > enable it to pass two Wins-server addresses to a client? If so, could > you possibly post the necessary patches to me? The CMU DHCP server (different tree from bootp-DD) does allow you to send WINS server addresses. We currently send two addresses to all our Windows 95/NT boxes. If I remember correctly (it's been a while and I didn't write the original), you need an entry at the top of your bootptab: ----- # The following lines have been added to provide DHCP support for Windows 95 # clients with the new server. They will cause false error messages with # old servers, but that shouldn't matter. $DHCP: ds=128.2.35.50 128.2.13.21 128.2.72.1:no=p:dl=86400:\ ws=128.2.35.60 128.2.72.50 $V37020000:tc=$DHCP ----- Where ds is domain, dl is lease time, and ws is WINS servers. The sources for DHCP 3.3.7 (which has known bugs, but few truly fatal ones) are available from ftp://ftp.net.cmu.edu/pub/dhcp. We'll be working on bug fixes and feature enhancements in the next couple of months. --- Erikas   Received: from cnri by ietf.org id aa28768; 10 Feb 97 13:15 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa17352; 10 Feb 97 13:15 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB23752; Mon, 10 Feb 1997 13:00:59 -0500 Date: Mon, 10 Feb 1997 13:00:59 -0500 Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Somenath Bandyopadhyay To: Multiple recipients of list Subject: WIN/95 Init State -Reply X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Novell GroupWise 4.1 I had the same problem and I used regedit and found where the DHCP structure is stored. And then delete the data in registry for the old IP address..In fact, I put 0's all over and WIN95 client got its IP address successfully when rebooted. This worked for me...thanks, som. >>> "Jeff Taylor" Taylor@zoo 02/07/97 03:53pm >>> All, I am noticing a problem with WIN/95. What determines that a client is supposed to do a DHCPDISCOVER & not a DHCPREQUEST I have noticed the problem when a client is given an address that is in conflict for some reason. Even though the address is removed from the pool of available addresses on the server, the client still requests the old address. How can you clear that address out of the client, so that it will do a DHCPDISCOVER? Jeff Taylor jefft@ou.edu Network Specialist Telecommunications Dept. University of Oklahoma   Received: from cnri by ietf.org id aa28782; 10 Feb 97 13:15 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa17357; 10 Feb 97 13:15 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA05932; Mon, 10 Feb 1997 13:01:51 -0500 Date: Mon, 10 Feb 1997 13:01:51 -0500 Message-Id: <01IF9BN3PNYU0003EI@INTEGD.INTEGRALIS.CO.UK> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: justin.clark@integralis.co.uk To: Multiple recipients of list Subject: X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Mime-Version: 1.0 subscribe ________________________________________________________ MIMEsweeper has scanned this message and its attachments and found it to be free of all known viruses. info@Integralis.com http://www.integralis.com Innovation, Integration, Integralis ________________________________________________________   Received: from cnri by ietf.org id aa09347; 10 Feb 97 16:57 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa23522; 10 Feb 97 16:57 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA28698; Mon, 10 Feb 1997 16:45:57 -0500 Date: Mon, 10 Feb 1997 16:45:57 -0500 Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: zliu1 To: Multiple recipients of list Subject: Re: WIN/95 Init State X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Mime-Version: 1.0 On Fri, 7 Feb 1997, "Jeff Taylor" Taylor@zoo wrote: > I am noticing a problem with WIN/95. What determines that a client is > supposed to do a DHCPDISCOVER & not a DHCPREQUEST > > I have noticed the problem when a client is given an address that is > in conflict for some reason. Even though the address is removed from > the pool of available addresses on the server, the client still > requests the old address. > > How can you clear that address out of the client, so that it will do > a DHCPDISCOVER? When the requested address is in conflict with bootptab, the DHCP server should send back a DHCPNAK reply, and the WIN95 client sending DHCPREQUEST will start DHCPDISCOVER all over again. Zuwei Liu Network Engineering University of Notre Dame   Received: from cnri by ietf.org id aa11726; 10 Feb 97 19:50 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa27341; 10 Feb 97 19:50 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB24189; Mon, 10 Feb 1997 19:32:28 -0500 Date: Mon, 10 Feb 1997 19:32:28 -0500 Message-Id: <199702102237.JAA16415@random.tpgi.com.au> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Matt Carling To: Multiple recipients of list Subject: Re: WIN/95 Init State -Reply X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Mime-Version: 1.0 X-Mailer: Microsoft Internet Mail 4.70.1155 Try running winipcfg (standard with win95). It allows you to view active leases and release them too. cheers Matt ---------- > From: Somenath Bandyopadhyay > To: Multiple recipients of list > Subject: WIN/95 Init State -Reply > Date: Tuesday, February 11, 1997 5:01 > > I had the same problem and I used regedit and found where > the DHCP structure is stored. And then delete the data in > registry for the old IP address..In fact, I put 0's all over and > WIN95 client got its IP address successfully when rebooted. > > This worked for me...thanks, som. > > >>> "Jeff Taylor" Taylor@zoo > 02/07/97 03:53pm >>> > All, > > I am noticing a problem with WIN/95. What determines that a > client is > supposed to do a DHCPDISCOVER & not a DHCPREQUEST > > I have noticed the problem when a client is given an address > that is > in conflict for some reason. Even though the address is > removed from > the pool of available addresses on the server, the client still > requests the old address. > > How can you clear that address out of the client, so that it will > do > a DHCPDISCOVER? > > > Jeff Taylor > jefft@ou.edu > Network Specialist > Telecommunications Dept. > University of Oklahoma >   Received: from cnri by ietf.org id aa26859; 12 Feb 97 19:06 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa23449; 12 Feb 97 19:06 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB15370; Wed, 12 Feb 1997 18:52:53 -0500 Date: Wed, 12 Feb 1997 18:52:53 -0500 Message-Id: <33026096.3165@wausau.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: cpeters2 To: Multiple recipients of list Subject: Re: client-id -Reply X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Mime-Version: 1.0 X-Mailer: Mozilla 3.0 (Win95; I; 16bit) What about sun systems with more than one network adapter? Sun uses one mac address for all its interfaces. Richard Letts wrote: > > On Fri, 24 Jan 1997, David Lapp wrote: > > > This is all true but client ids in many (most? all?) implementations > > are user/customer entered and controled. Thus, this is an administrative > I hope not! In the environment I'm using bootp [and will shortly move > to DHCP] The last thing I want is users having to remember something > cryptic that they then try to use on every PC they try. 91% of the > systems at work obtain their IP addresses dynamically. the other 9% are > unix servers and network hardware. > > I'd assumed everyone would use the burnt-in mac address of the IEEE network > adapter: why complicate things generating client ID's any hard way. > > Richard Letts > --------------------------------------------------------------------------- > Network Services Manager mail: R.J.Letts@ais.salford.ac.uk > University of Salford phone: +44 161 745 5252 > Great Britain fax: +44 161 745 5888   Received: from cnri by ietf.org id aa18147; 17 Feb 97 11:45 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa19702; 17 Feb 97 11:45 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB15457; Mon, 17 Feb 1997 11:33:27 -0500 Date: Mon, 17 Feb 1997 11:33:27 -0500 Message-Id: <2.2.32.19970217112934.0069a6b8@quadalpha.quadritek.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Arun Kapur To: Multiple recipients of list Subject: subscribe akapur@quadritek.com X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Mime-Version: 1.0 X-Mailer: Windows Eudora Pro Version 2.2 (32)   Received: from cnri by ietf.org id aa18154; 17 Feb 97 11:45 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa19718; 17 Feb 97 11:45 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AC02276; Mon, 17 Feb 1997 11:30:04 -0500 Date: Mon, 17 Feb 1997 11:30:04 -0500 Message-Id: <2.2.32.19970217111343.006797e0@quadalpha.quadritek.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Arun Kapur To: Multiple recipients of list Subject: subscribe X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Mime-Version: 1.0 X-Mailer: Windows Eudora Pro Version 2.2 (32) subscribe Arun Kapur ________________ (email akapur@quadritek.com)   Received: from cnri by ietf.org id aa00099; 17 Feb 97 16:39 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa11622; 17 Feb 97 16:39 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA18816; Mon, 17 Feb 1997 16:37:02 -0500 Date: Mon, 17 Feb 1997 16:37:02 -0500 Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ramesh Vyaghrapuri To: Multiple recipients of list Subject: X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 subscribe host-conf rameshv@microsoft.com   Received: from cnri by ietf.org id aa16109; 21 Feb 97 13:42 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa19413; 21 Feb 97 13:42 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB05575; Fri, 21 Feb 1997 13:37:41 -0500 Date: Fri, 21 Feb 1997 13:37:41 -0500 Message-Id: <330DC247.2834@chevron.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Michael J. Lewis" To: Multiple recipients of list Subject: Dynamic DNS and existing DHCP clients X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Mime-Version: 1.0 X-Mailer: Mozilla 3.0 (Win95; I) We're in the process of examining our first "standards-based" DDNS/DHCP implementation. As a part of this evaluation, we are testing to see how well the product adheres to the "Interaction between DHCP and DNS" draft (draft-ietf-dhc-dhcp-dns-02.txt) and "Dynamic Updates in the Domain Name System" (draft-ietf-dnsind-dynDNS-11.txt) documents. The server product appears to follow the DNS update document but because the client is one of the current lot, the specifications of the DHCP/DNS interaction document are not followed. As I read the document, a client wishing to utilize a dynamic DNS update must send a Client FQDN option to the server indicating whether the client or server will update the A RR record. The document does not cover what should occur if this option is not provided; the implication is that no dynamic DNS update should occur. This is a problem, of course, for those of us with existing DHCP clients that do not include the Client FQDN option. The DDNS/DHCP vendor we tested skirted the issue by providing configuration options that allow the server to initiate the updates at the discretion of the system administrator rather than the client. The FQDN is built by combining the domain name with either host name information provided on the client's DHCP DISCOVER/REQUEST packets or generated via conventions set by the administrator. I understand that a scenario in which the server does all DNS activity is not perfect (a client could RELEASE its address while the DHCP server were down and consequently no DNS update would occur) but this vendor's implementation seems to provide a way in which those of us who have (large numbers) of existing DHCP clients could get to a Dynamic DNS solution by updating our (fewer) servers rather than our (many) clients. Would it make sense to amend the draft to allow a server to undertake all DNS updates (at administrator/site discretion) if the Client FQDN packet is not included within a client's REQUEST packet? Thanks.   Received: from cnri by ietf.org id aa19276; 21 Feb 97 15:30 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa22128; 21 Feb 97 15:30 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA03333; Fri, 21 Feb 1997 15:24:17 -0500 Date: Fri, 21 Feb 1997 15:24:17 -0500 Message-Id: <199702211841.KAA07603@puli.cisco.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Yakov Rekhter To: Multiple recipients of list Subject: Re: Dynamic DNS and existing DHCP clients X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Michael, > We're in the process of examining our first "standards-based" DDNS/DHCP > implementation. As a part of this evaluation, we are testing to see how > well the product adheres to the "Interaction between DHCP and DNS" draft > (draft-ietf-dhc-dhcp-dns-02.txt) and "Dynamic Updates in the Domain Name > System" (draft-ietf-dnsind-dynDNS-11.txt) documents. The server product > appears to follow the DNS update document but because the client is one > of the current lot, the specifications of the DHCP/DNS interaction > document are not followed. > > As I read the document, a client wishing to utilize a dynamic DNS update > must send a Client FQDN option to the server indicating whether the > client or server will update the A RR record. The document does not > cover what should occur if this option is not provided; the implication > is that no dynamic DNS update should occur. > > This is a problem, of course, for those of us with existing DHCP clients > that do not include the Client FQDN option. The DDNS/DHCP vendor we > tested skirted the issue by providing configuration options that allow > the server to initiate the updates at the discretion of the system > administrator rather than the client. The FQDN is built by combining > the domain name with either host name information provided on the > client's DHCP DISCOVER/REQUEST packets or generated via conventions set > by the administrator. > > I understand that a scenario in which the server does all DNS activity > is not perfect (a client could RELEASE its address while the DHCP server > were down and consequently no DNS update would occur) but this vendor's > implementation seems to provide a way in which those of us who have > (large numbers) of existing DHCP clients could get to a Dynamic DNS > solution by updating our (fewer) servers rather than our (many) clients. > Would it make sense to amend the draft to allow a server to undertake > all DNS updates (at administrator/site discretion) if the Client FQDN > packet is not included within a client's REQUEST packet? I think this is quite reasonable modification. So, unless I hear any stong objections I'll reissue the Internet Draft with this mod included. Yakov. P.S. I also wonder whether even if a client indicates to a server that the client wants to update its A RR, the serve should be allowed (under administrative control) to override this by (a) taking responsibility for update the A RR, and (b) indicating to the client that the server decided to take this responsibility. Any comments on this ?   Received: from cnri by ietf.org id aa19373; 21 Feb 97 15:33 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa22202; 21 Feb 97 15:33 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA11341; Fri, 21 Feb 1997 15:27:20 -0500 Date: Fri, 21 Feb 1997 15:27:20 -0500 Message-Id: <199702211956.LAA00953@andare.fugue.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Dynamic DNS and existing DHCP clients X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Would it make sense to amend the draft to allow a server to undertake > all DNS updates (at administrator/site discretion) if the Client FQDN > packet is not included within a client's REQUEST packet? I'm not sure there's any reason to do this - this seems to be a non-DHCP-specific feature provided by a DHCP server, rather than a DHCP-specific feature that needs to be documented in a protocol standard. _MelloN_   Received: from cnri by ietf.org id aa22369; 21 Feb 97 17:47 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa25896; 21 Feb 97 17:47 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB05365; Fri, 21 Feb 1997 17:43:42 -0500 Date: Fri, 21 Feb 1997 17:43:42 -0500 Message-Id: <330E0C0F.3537@chevron.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Michael J. Lewis" To: Multiple recipients of list Subject: Re: Dynamic DNS and existing DHCP clients X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Mime-Version: 1.0 X-Mailer: Mozilla 3.0 (Win95; I) Yakov Rekhter wrote: > > Michael, > < original suggestion deleted > > > Would it make sense to amend the draft to allow a server to undertake > > all DNS updates (at administrator/site discretion) if the Client FQDN > > packet is not included within a client's REQUEST packet? > I think this is quite reasonable modification. So, unless I hear > any stong objections I'll reissue the Internet Draft with this > mod included. > > Yakov. > > P.S. I also wonder whether even if a client indicates to a server > that the client wants to update its A RR, the server should be > allowed (under administrative control) to override this by (a) taking > responsibility for update the A RR, and (b) indicating to the client > that the server decided to take this responsibility. Any comments > on this ? This sounds fine to me.   Received: from cnri by ietf.org id aa23410; 21 Feb 97 18:34 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa26877; 21 Feb 97 18:34 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB25005; Fri, 21 Feb 1997 18:30:22 -0500 Date: Fri, 21 Feb 1997 18:30:22 -0500 Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Bo Ahlberg To: Multiple recipients of list Subject: Questions on why DHCP Clients can issue DNSUPD messages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 Please pardon any ignorance here.... but having just started monitoring these groups and having read a number of the drafts, I have found an issue that I must call attention to: The issue has to do with DynDNS, DHCP and Client driven updates. The issue that seems to be un-addressed here is security and its impact upon the management side of the problems of Dynamic Address management. My point being: 1. DNSSEC seems to indicate that the method used to validate a host/client's right to update DNS entries is to be granted by a security record maintained in the config files of the DNS to be updated. 2. DNSUPD indicates that the DHCP client can declare that it will provide the DNSUPD messages to the DNS. 3. DHCP server is in fact the owner of the lease, the client is just the "borrower". So, what this seems to mean is that if I want to protect my DynDNS from attack by unauthorized DNSUPD messages I will need to maintain security records for each client so authorized. Which in turn leads to the question: "what problem is trying to be solved here?" If, as seems to be the intent of the DynDNS, you are trying to reduce the load of maintaining the Config and Zone files of the DNS by allowing the DNS to by automatically maintained with regards to the IP address and name assignments. Then why is a situation being created where in the IP Address/Domain Name management load is being shifted to managing security records? (Aren't we just trading one kind of static space (Name to IP address) for another (Security record to Network ID)? Further, since the DHCP server is the owner of all IP address leases, should not the DHCP server be the only one to issue updates for its granted leases? (This would help reduce the security info management by maintaining DNSSEC records for the DHCP server and not hundreds of clients). If the issue for allowing the DHCP clients to update the DynDNS is to allow for "unavailable" DHCP servers? Then why not address the DHCP server short comings by allowing fault tolerant DHCP configurations? ( As is being suggested by the use of the Server Cache Synchronization Protocol to allow multiple DHCP server to coordinate within a lease scope [and if that has not been suggested, it has now].) It would seem to me that the following would be natural evolution to the existing systems to allow the dynamic configuration of the DNS and controlling the security of the information. 1. DNSUPD from clients is only allowed if they have been statically assigned an IP address. (this is no net increate in work for the DNS Manager as the change is from maintaining A records to managing security records). 2. DHCP Clients are forbidden from DNSUPD messages as they are not the owner of the address (By allowing DHCP Clients to do DNSUPD messages you are not saving any work in a secure environment.) 3. DHCP Servers and their related protocols be extended to allow for the creation of fault tolerant Server environments (SCSP is a start). This would remove, or limit, the requirements for client based DNSUPD messages. 4. If security of network clients is an issue, then extend DHCP Servers do security checking on those clients using any of a number of security models (Kerberos for example). The DHCP server is the client's first point of contact in the network (generally speaking) and as such is in an ideal situation to validate a client by issuing it an IP Address (and potentially other access keys). Please... I am not trying to dig up potentially old ground.... I have just been reading through the various documents from both the DNS and DHCP groups and found what I thought were some inconsistencies. I wanted to find out if there was an answer to my questions since the documents I have found to date don't seem to provide any. Thanks in advance.... Bo.... Bo Ahlberg Senior Network Engineer/Lead Technologist ------------------------------------------------------- MetaInfo, Inc. "Making the Net Work!" 119 S. Main St. Suite 200 Voice: 206.674.3700 Seattle, WA 98104 USA Fax: 206.674.3800 ------------------------------------------------------- http://www.metainfo.com >   Received: from cnri by ietf.org id aa26731; 21 Feb 97 21:53 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa00195; 21 Feb 97 21:53 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA00539; Fri, 21 Feb 1997 21:50:40 -0500 Date: Fri, 21 Feb 1997 21:50:40 -0500 Message-Id: <199702220242.VAA07893@geordi.dccs.upenn.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Dikran Kassabian To: Multiple recipients of list Subject: Re: Questions on why DHCP Clients can issue DNSUPD messages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Mail User's Shell (7.2.5 10/14/92) On Feb 21, 6:30pm, Bo Ahlberg wrote: | Which in turn leads to the question: "what problem is trying to be | solved here?" That seems to me to be a fair question. | If, as seems to be the intent of the DynDNS, you are trying to reduce | the load of maintaining the Config and Zone files of the DNS by allowing | the DNS to by automatically maintained with regards to the IP address | and name assignments. Then why is a situation being created where in the | IP Address/Domain Name management load is being shifted to managing | security records? (Aren't we just trading one kind of static space (Name | to IP address) for another (Security record to Network ID)? I guess when you have strong tools, you can sometimes apply them to numerous problems. Some people are more interested in solving a different problem than the one you state: That of getting addresses assigned dynamically but allowing for cases where a specific FQDN should follow the actual end-station regardless of what address it has been assigned (and to some extent, regardless of where it is from a network topological standpoint). That is to say, I might want to move my laptop to different buildings and different networks around my campus (or perhaps even to a neighboring campus!) and get new address assignments as needed from a number of different DHCP servers, but *always* end up with the FQDN "artoo.dccs.upenn.edu". It's no less work than managing static addresses (it may be more work) but it achieves something new. | Further, since the DHCP server is the owner of all IP address leases, | should not the DHCP server be the only one to issue updates for its | granted leases? (This would help reduce the security info management by | maintaining DNSSEC records for the DHCP server and not hundreds of | clients). The DHCP server owns the address. So it ought to perform the DNS PTR record update. Who owns the name, and therefore has the right to do the DNS A record update, is a question that could have different answers in different situations. ------- Deke Kassabian, Manager, Network Engineering Information Systems and Computing, University of Pennsylvania Voice:215-898-9293 FAX:215-898-9348 Email:   Received: from cnri by ietf.org id aa14871; 22 Feb 97 11:49 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa11836; 22 Feb 97 11:49 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA10390; Sat, 22 Feb 1997 11:44:24 -0500 Date: Sat, 22 Feb 1997 11:44:24 -0500 Message-Id: <9702221633.AA10775@wasted.zk3.dec.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: bound@zk3.dec.com To: Multiple recipients of list Subject: Re: Dynamic DNS and existing DHCP clients X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Yakov, THe implementation I am building assumes the policy is in place per your draft (I am only working on DHCPv6). So if the server updates ptr and client updates AAAA records and client sends AAAA then the server will reject the request. So I don't have an issue with this either. /jim   Received: from cnri by ietf.org id aa14881; 22 Feb 97 11:49 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa11841; 22 Feb 97 11:49 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AE29378; Sat, 22 Feb 1997 11:45:24 -0500 Date: Sat, 22 Feb 1997 11:45:24 -0500 Message-Id: <9702221636.AA10906@wasted.zk3.dec.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: bound@zk3.dec.com To: Multiple recipients of list Subject: Re: Dynamic DNS and existing DHCP clients X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 thats a good point too. dyn dns support is really out of scope for dhcp. but in dhcpv6 we do have error codes defined for the server and request types in the extensions so Yakov's various scenarios can be known when I send the packet as a client and when I receive the packet as a server. I just parse the ext type and see if AAAA || PTR || BOTH. Same code for client and server so the model works well. /jim   Received: from cnri by ietf.org id aa15347; 22 Feb 97 12:21 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa12372; 22 Feb 97 12:21 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA26945; Sat, 22 Feb 1997 12:18:34 -0500 Date: Sat, 22 Feb 1997 12:18:34 -0500 Message-Id: <9702221646.AA08191@wasted.zk3.dec.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: bound@zk3.dec.com To: Multiple recipients of list Subject: Re: Questions on why DHCP Clients can issue DNSUPD messages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 these points are issues we really did not discuss. but I think that the policy has to set based on who can upate what. thats why I think the market will either haver servers do it or clients do it but not have it split. this reduces the security problem somewhat and the fault tolerant issues to at least once system. it also gets more complicate for IPv6. here i can be getting addresses from a routing adverstisement prefix and from dhcpv6. what I am going to build in my implementation for ipv6 is a client that does the AAAA and ptr record directly with the dns and will have its own security mappings (also different levels available). the lease (stateless or dhcpv6 assigned) will determine the delete to the dns and will happen automatically from the dynds daemon. we have a lot more tools to do this in IPv6 and DHCPv6 protocol so I beginning to think that the way its done will be different due to the two different capabilities. also we did not do dyndns to reduce config files (made it better to update them with notify and ixfr thought) but rather to take humans out of the loop for names/ptrs. of course we increased the overhead. /jim   Received: from cnri by ietf.org id aa22447; 22 Feb 97 19:05 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa18356; 22 Feb 97 19:05 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB24725; Sat, 22 Feb 1997 18:58:13 -0500 Date: Sat, 22 Feb 1997 18:58:13 -0500 Message-Id: <199702222334.PAA00577@andare.fugue.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Questions on why DHCP Clients can issue DNSUPD messages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > I think that the policy has to set based on who can upate what. > thats why I think the market will either haver servers do it or > clients do it but not have it split. this reduces the security > problem somewhat and the fault tolerant issues to at least once > system. I'd trust my laptop at a customer site before I'd trust the DHCP server at a customer site. But the name server at the customer site would rightly trust its DHCP server more than my laptop. This is the reason why we need to be able to do split updates. For machines that will never leave an administrative domain, single-source updates make a lot of sense, but that's not the only case we should be thinking about. > also we did not do dyndns to reduce config files (made it better to > update them with notify and ixfr thought) but rather to take humans out > of the loop for names/ptrs. of course we increased the overhead. Nicely put. I think this can be said about the DHCP protocol in general, and it shouldn't be thought of as a criticism. _MelloN_   Received: from cnri by ietf.org id aa12985; 23 Feb 97 12:33 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa11782; 23 Feb 97 12:33 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB26123; Sun, 23 Feb 1997 12:28:12 -0500 Date: Sun, 23 Feb 1997 12:28:12 -0500 Message-Id: <9702231657.AA20161@wasted.zk3.dec.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: bound@zk3.dec.com To: Multiple recipients of list Subject: Re: Questions on why DHCP Clients can issue DNSUPD messages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 >> I think that the policy has to set based on who can upate what. >> thats why I think the market will either haver servers do it or >> clients do it but not have it split. this reduces the security >> problem somewhat and the fault tolerant issues to at least once >> system. >I'd trust my laptop at a customer site before I'd trust the DHCP >server at a customer site. But the name server at the customer site >would rightly trust its DHCP server more than my laptop. This is the >reason why we need to be able to do split updates. For machines that >will never leave an administrative domain, single-source updates make >a lot of sense, but that's not the only case we should be thinking >about. Good point. The issue also becomes a problem for IPv6 when you come on the link and get a prefix for your interface-id and then want a name. So it seems that the server needs to authenticate each client. But if the client is authenticated by DHCP in the first place to the server then the server can use a "generic SIG record" to update any clients???? This would reduce the SIG records. For permanent clients not using DHCP they would need their own SIG records. But now we are tying SIG records to addresses and that we better check will work in DNSSEC? /jim   Received: from cnri by ietf.org id aa17521; 23 Feb 97 17:46 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa16268; 23 Feb 97 17:46 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AD32704; Sun, 23 Feb 1997 17:41:42 -0500 Date: Sun, 23 Feb 1997 17:41:42 -0500 Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mike Carney - SunSoft Internet Engineering To: Multiple recipients of list Subject: Re: DHCPNAK and multiple logical subnet issue X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Hi All, I realize that Munil sent this out awhile back, but better late than never. ;^) > Here's the setup. I have multiple logical subnets A and B on same > physical net. DHCP client gets an IP address from DHCPServer-A. On the > next reboot, it broadcasts DHCPREQUEST. Server A gets it and sends an > DHCPACK. Server B also gets the same request and sends a DHCPNAK as per > draft-ietf-dhc-dhcp-09.txt, section 4.3.2, topic DHCPREQUEST generated > during INIT-REBOOT state. The client happens to get the DHCPNAK first > and that forces him to get a new IP address even though its lease for > the previous IP address is still valid. This in turn causes DNS and NBNS > entries for this client to get updated and extra network traffic. > > How do I fix this? There are several issues/suggestions. > I suppose servers that support this feature can be configured with a list of logical networks to physical media, and thus check all logical networks upon receipt of a client request to see "which" network the client is "really" on. Clients wouldn't have to change. I imagine that this solution doesn't scale very well, as the number of clients and logical networks increase, particularly in the absence of a server-to-server protocol. Munil's suggestion of using the subnet broadcast address rather than the limited broadcast address (255.255.255.255) would work as well, although that solution would only help in the INIT-REBOOT state - if the client's lease expires, then the knowledge of the netmask goes with it. And, as Munil pointed out, this solution wouldn't effectively detect the situation when the client actually *has* moved to a different net, and should thus be NAKed. Adding a client and server configurable option which would serve as a logical network identifier would work, although this would further complicate the situation where the client really "does" move, requires client configuration, and wouldn't help legacy clients. Ultimately, I imagine the site looks like a BOOTP site (no automatic allocation). The only truly effective mechanism is found at the link layer, where switches are configured such that some list of ports is on one network, and another list is on another network, and so on. You're still using the same wire, but you're getting the one network to one physical ethernet that's required to make DHCP work effectively. You can't do this with routers. Mike Carney SunSoft Internet Engineering Sun Microsystems, Inc. 2 Elizabeth Drive Chelmsford, MA 01824   Received: from cnri by ietf.org id aa18700; 23 Feb 97 19:07 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa17421; 23 Feb 97 19:06 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA11306; Sun, 23 Feb 1997 19:01:51 -0500 Date: Sun, 23 Feb 1997 19:01:51 -0500 Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mike Carney - SunSoft Internet Engineering To: Multiple recipients of list Subject: Re: Dynamic DNS and existing DHCP clients X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > > > Would it make sense to amend the draft to allow a server to undertake > > all DNS updates (at administrator/site discretion) if the Client FQDN > > packet is not included within a client's REQUEST packet? > > I'm not sure there's any reason to do this - this seems to be a > non-DHCP-specific feature provided by a DHCP server, rather than a > DHCP-specific feature that needs to be documented in a protocol > standard. > > _MelloN_ I agree. Keeping DHCP separate from DDNS protocols is important. (that's different than combining functionality in a implementation, which is what I think Michael was describing) Mike Carney SunSoft Internet Engineering Sun Microsystems, Inc. 2 Elizabeth Drive Chelmsford, MA 01824   Received: from cnri by ietf.org id aa14772; 24 Feb 97 18:47 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa25875; 24 Feb 97 18:47 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AC02911; Mon, 24 Feb 1997 18:38:36 -0500 Date: Mon, 24 Feb 1997 18:38:36 -0500 Message-Id: <199702242255.OAA00629@andare.fugue.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Questions on why DHCP Clients can issue DNSUPD messages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Please pardon any ignorance here.... but having just started monitoring > these groups and having read a number of the drafts, I have found an > issue that I must call attention to: Sigh. Had you subscribed about a day earlier, you would have seen an exchange on this very topic. Oh well - life doesn't always proceed in the most convenient possible manner... :') Anyway, the reason why both the client and the server may need to send updates to the name server is that it may be necessary to update two name servers. Consider the case (which is very near and dear to me, BTW) where you have a laptop that you carry around between work and customer sites. My laptop is andare.fugue.com. As the laptop moves around, it needs to acquire addresses from various dhcp servers (or, on some nets, it uses a static address which it verifies by pinging the router). When it gets a new address, it should contact the DNS server at home with a DNS update for the A record for andare.fugue.com. Meanwhile, the DHCP server from which it got its address needs to send a DNS update to *it's* name server for the PTR record linking the local address with the domain name ``andare.fugue.com.'' I do not want to set my DNS server up so that it trusts my customers' DHCP servers to do A record updates. My customers don't want to set their DNS servers up so that my laptop can update PTR records. So, it is necessary to do a split update, with the laptop updating my DNS server's A record and the local DHCP server updating the local DNS server's PTR record. Of course, I haven't yet implemented the DNS update code, but it's next on my list. Sigh. _MelloN_   Received: from cnri by ietf.org id aa18683; 25 Feb 97 11:48 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa14573; 25 Feb 97 11:48 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB03230; Tue, 25 Feb 1997 11:38:57 -0500 Date: Tue, 25 Feb 1997 11:38:57 -0500 Message-Id: <01BC2308.145BC3C0@glennlaptop.raleigh.ibm.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Glenn Stump To: Multiple recipients of list Subject: RE: Dynamic DNS and existing DHCP clients X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BC2308.145BC3C0" Mime-Version: 1.0 ------ =_NextPart_000_01BC2308.145BC3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yakov, Michael, In case you need yet another opinion... I believe the choice by the server to update DNS RR's is strictly server implementation and/or local admin policy (regardless of whether or not option 81 is included). To address Yakov's last question of: > P.S. I also wonder whether even if a client indicates to a server > that the client wants to update its A RR, the serve should be > allowed (under administrative control) to override this by (a) taking > responsibility for update the A RR, and (b) indicating to the client > that the server decided to take this responsibility. Any comments > on this ? I say "yes" here, as well... and so I guess I'd agree that some new text (as an implementation note?) would be helpful in clarifying this issue. Regards, Glenn ------ =_NextPart_000_01BC2308.145BC3C0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+Ii4PAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYA0AQAAAMAAAAQAAAAAwAAMAQAAAAL AA8OAQAAAAIB/w8BAAAAPwAAAAAAAAD+QqoKGMcaEOiFC2UcJAAAAwAAAAQAAAAAAAAAGAAAAAAA AADEXkoGSXvPEbGEREVTVAAAxBomAHxDqwAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAEAAA AHlha292QGNpc2NvLmNvbQADABUMAQAAAAMA/g8GAAAAHgABMAEAAAAXAAAAWWFrb3YgUmVraHRl ciAoRS1tYWlsKQAAAgELMAEAAAAVAAAAU01UUDpZQUtPVkBDSVNDTy5DT00AAAAAAwAAOQAAAAAL AEA6AAAAAB4A9l8BAAAAFwAAAFlha292IFJla2h0ZXIgKEUtbWFpbCkAAAIB918BAAAAPwAAAAAA AAD+QqoKGMcaEOiFC2UcJAAAAwAAAAQAAAAAAAAAGAAAAAAAAADEXkoGSXvPEbGEREVTVAAAxBom AAAAAAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAABBAAAAADAAAwBQAAAAsADw4BAAAA AgH/DwEAAABBAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAEATWljaGFlbCBKLiBMZXdpcwBTTVRQ AGhvc21qbEBjaGV2cm9uLmNvbQAAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAEwAAAGhv c21qbEBjaGV2cm9uLmNvbQAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAAEwAAACdNaWNoYWVsIEou IExld2lzJwAAAgELMAEAAAAYAAAAU01UUDpIT1NNSkxAQ0hFVlJPTi5DT00AAwAAOQAAAAALAEA6 AAAAAB4A9l8BAAAAJgAAAE1pY2hhZWwgSi4gTGV3aXMgW2hvc21qbEBjaGV2cm9uLmNvbV0AAAAC AfdfAQAAAEEAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAQBNaWNoYWVsIEouIExld2lzAFNNVFAA aG9zbWpsQGNoZXZyb24uY29tAAAAAAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAAFEAAA AAMAADAGAAAACwAPDgAAAAACAf8PAQAAAEcAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABkaGNw LXY0QGJ1Y2tuZWxsLmVkdQBTTVRQAGRoY3AtdjRAYnVja25lbGwuZWR1AAAeAAIwAQAAAAUAAABT TVRQAAAAAB4AAzABAAAAFQAAAGRoY3AtdjRAYnVja25lbGwuZWR1AAAAAAMAFQwCAAAAAwD+DwYA AAAeAAEwAQAAABcAAAAnZGhjcC12NEBidWNrbmVsbC5lZHUnAAACAQswAQAAABoAAABTTVRQOkRI Q1AtVjRAQlVDS05FTEwuRURVAAAAAwAAOQAAAAALAEA6AQAAAB4A9l8BAAAAFQAAAGRoY3AtdjRA YnVja25lbGwuZWR1AAAAAAIB918BAAAARwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAGRoY3At djRAYnVja25lbGwuZWR1AFNNVFAAZGhjcC12NEBidWNrbmVsbC5lZHUAAAMA/V8BAAAAAwD/XwAA AAACAfYPAQAAAAQAAAAAAAAG3OsBBIABACsAAABSRTogRHluYW1pYyBETlMgYW5kIGV4aXN0aW5n IERIQ1AgY2xpZW50cyAACg4BBYADAA4AAADNBwIAGQAKACYAGQACADoBASCAAwAOAAAAzQcCABkA CQApAAAAAgAjAQEJgAEAIQAAADFGNTFDQTg4RjA4RUQwMTFCMTg1NDQ0NTUzNTQwMDAwANwGAQOQ BgAwBgAAIQAAAAsAAgABAAAACwAjAAAAAAADACYAAAAAAAsAKQAAAAAAAwAuAAAAAAADADYAAAAA AEAAOQCgTYfwMSO8AR4AcAABAAAAKwAAAFJFOiBEeW5hbWljIEROUyBhbmQgZXhpc3RpbmcgREhD UCBjbGllbnRzIAAAAgFxAAEAAAAWAAAAAbwjMetziMpRL47wEdCxhURFU1QAAAAAHgAeDAEAAAAF AAAAU01UUAAAAAAeAB8MAQAAABYAAABzdHVtcEByYWxlaWdoLmlibS5jb20AAAADAAYQQYLPkAMA BxBpAgAAHgAIEAEAAABlAAAAWUFLT1YsTUlDSEFFTCxJTkNBU0VZT1VORUVEWUVUQU5PVEhFUk9Q SU5JT05JQkVMSUVWRVRIRUNIT0lDRUJZVEhFU0VSVkVSVE9VUERBVEVETlNSUlNJU1NUUklDVExZ U0VSVgAAAAACAQkQAQAAAP0CAAD5AgAASgQAAExaRnU9HM34dwAKAQMB9yACpAPjAgBjgmgKwHNl dDAgBxOHAoMAUA72cHJxMg/2Jn0KgAjIIDsJbzI1ZjUCgAqBdWMAUAsDYwMAQQtgbmcxMDMzAQum IFlha292LIogBdBpD3FlbCwKoksKhAqASQOgY2EPsCDSeQhgIG4J4GQYkA/AIiAAcG90aASQIG9q cAuAaQIgLhpgFsBJ7RdkYhcwCJB2GIAZoRhAzGhvFvAYgGJ5G5MPsAZyG3AFwHRvIHVwSGRhdBiA RE4F8FK8UicEIRdzBAAcsHQFEHhjdGwcYBzFB3ALUGWfB4ACMB2QGjEZYWQvBbFHCQAYUAMgYWRt C4AgXnAG8BbwHGAXZCgJcGeHCxEgIAQRb2YgdxmwnxmkBcAZgRnhIJM4MR/gmwQgC4BjCkABAGQp GoHuVB1AF2QhsGQJcAQRFmPnHjELYB7wIHEKUB7wIKIdI6A6F2oVAQ/gPiBQlC5TGoBJGWBscx1A /ncCIASBI8cbYQOgBpAZYO8YQBtBAjAlgWQW8B2RBCD/HTEsUBzEF2QqABmgHZAblLUshHcAcHQt Yx1laS/hPkEeARawHIccsBvwdWy/GRAbIB5VKgAHQAkAdxkB/Ch1KwMhswQAHwAggRtx5wWgAjAD YGwpHSIWkASQnwUQAQAbkR7BHFEoYTVhexZwC4BnMocnESIQAIFi/wMQMLAcYAIQBcAdZRuiMPT7 IOEzgGI1YCzlNzIdMS8I/y4/HMUFgTYBGRA7YhZwNiWzN/wagEFuHGAFoG0gQu8PQC5FILE2Qz8p VyVAHlUpKnBzYRxgIhkwcyL6IBmxZToRBCAzUDMgGmI3OjIqsSpwZyhBBCBJJ30ZEGEJwi6kKrAH gBjRd/sXZB2geAVANsAEIAORH/15GYFlPzVgKuAyJRmwbHxwZjIgJYEsYQrABpB5VzsjNlIeZnMK UC4XalLVIwNzFrBHICBuC5AXd38LMSkcCqADYB2gHzAQhDEWNhdkEgEAUZAAAAADABAQAAAAAAMA ERAAAAAAAwCAEP////9AAAcw4O7l6ikjvAFAAAgw4O7l6ikjvAELAAaACCAGAAAAAADAAAAAAAAA RgAAAAADhQAAAAAAAAMACIAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwALgAggBgAAAAAA wAAAAAAAAEYAAAAAUoUAALcNAAAeACuACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4 LjAAAwAsgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALADWACCAGAAAAAADAAAAAAAAARgAA AAAOhQAAAAAAAAMANoAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwA4gAggBgAAAAAAwAAA AAAAAEYAAAAAGIUAAAAAAAAeAEeACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAA HgBIgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ASYAIIAYAAAAAAMAAAAAA AABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAAAAUAAABSRTogAAAAAAMADTT9NwAA1V0= ------ =_NextPart_000_01BC2308.145BC3C0--   Received: from cnri by ietf.org id aa22642; 25 Feb 97 13:33 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa17283; 25 Feb 97 13:33 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB23183; Tue, 25 Feb 1997 13:28:04 -0500 Date: Tue, 25 Feb 1997 13:28:04 -0500 Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Noel Johnston To: Multiple recipients of list Subject: Re: Questions on why DHCP Clients can issue DNSUPD messages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mime-Version: 1.0 Ted I have two questions for you regarding the scenario you presented below. I am curious as to how the laptop at the customer site is going to get its DNS update to your home server. 1. Would this update be a UDP (or TCP) unicast as per Sect 4 of RFC1035? (This is my understanding from the current drafts) 2. Most firewall administrators would be nervous about opening up this type of traffic between corporations don't you think? I know that it would certainly be the case at this client site. Currently the only DNS exchange between hosts at this site and other corporations is between an external (split DNS) server and the rest of the world. Internal hosts query an internal (behind the firewall) DNS and never communicate directly with DNS servers outside the corporation. On Mon, 24 Feb 1997, Ted Lemon wrote: > > Anyway, the reason why both the client and the server may need to send > updates to the name server is that it may be necessary to update two > name servers. Consider the case (which is very near and dear to me, > BTW) where you have a laptop that you carry around between work and > customer sites. My laptop is andare.fugue.com. > > As the laptop moves around, it needs to acquire addresses from various > dhcp servers (or, on some nets, it uses a static address which it > verifies by pinging the router). When it gets a new address, it > should contact the DNS server at home with a DNS update for the A > record for andare.fugue.com. > > Meanwhile, the DHCP server from which it got its address needs to send > a DNS update to *it's* name server for the PTR record linking the > local address with the domain name ``andare.fugue.com.'' > > I do not want to set my DNS server up so that it trusts my customers' > DHCP servers to do A record updates. My customers don't want to set > their DNS servers up so that my laptop can update PTR records. So, > it is necessary to do a split update, with the laptop updating my DNS > server's A record and the local DHCP server updating the local DNS > server's PTR record. > > Of course, I haven't yet implemented the DNS update code, but it's > next on my list. Sigh. > > _MelloN_ > Noel C Johnston Network Consultant Tel: 1-510-675 3050 (Work) Axis Consulting International Inc. 1-510-673 9636 (Home) 1 Maritime Plaza 24th Floor EMail: noel@yobbo.com San Francisco CA 94111 USA   Received: from cnri by ietf.org id aa26862; 25 Feb 97 15:30 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa20422; 25 Feb 97 15:30 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB19806; Tue, 25 Feb 1997 15:23:24 -0500 Date: Tue, 25 Feb 1997 15:23:24 -0500 Message-Id: <199702251818.KAA00763@andare.fugue.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Questions on why DHCP Clients can issue DNSUPD messages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > 1. Would this update be a UDP (or TCP) unicast as per Sect 4 of RFC1035? > (This is my understanding from the current drafts) Without non-host-based authentication, it really couldn't work, but yes, assuming non-host-based authentication, you would just do a regular DNS update. > 2. Most firewall administrators would be nervous about opening up this > type of traffic between corporations don't you think? I think ``most'' is probably an exaggeration, but yes, this could easily be a problem. However, in situations like this, trusting the local DNS server doesn't solve the problem - it doesn't help to do a DNS update if hosts off the network can't get to you anyway. One of my customer sites doesn't allow POP or SMTP through the firewall, and at that site, updating DNS would be a mistake, since my laptop would be unable to communicate anyway. Unfortunately, there's no way to account for the presence of an Internet Firewall in the average protocol standard. We have to assume that the network is functional. If it's not, the protocol fails. The whole point of a firewall is to make sure that certain protocols fail, after all. _MelloN_   Received: from cnri by ietf.org id aa06784; 25 Feb 97 18:51 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa25450; 25 Feb 97 18:50 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA29807; Tue, 25 Feb 1997 18:47:00 -0500 Date: Tue, 25 Feb 1997 18:47:00 -0500 Message-Id: <3.0.32.19970225141154.0069e2f4@qsun.att.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Robert G. Cole" To: Multiple recipients of list Subject: Re: Questions on why DHCP Clients can issue DNSUPD messages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Pro Version 3.0 (32) Bo, At 06:29 PM 2/21/97 -0500, you wrote: > >If the issue for allowing the DHCP clients to update the DynDNS is to >allow for "unavailable" DHCP servers? Then why not address the DHCP >server short comings by allowing fault tolerant DHCP configurations? ( >As is being suggested by the use of the Server Cache Synchronization >Protocol to allow multiple DHCP server to coordinate within a lease >scope [and if that has not been suggested, it has now].) > It has been suggested (please see my posting to the DHCP server-to-server mailing list. If you missed it, I'll be glad to resend it to you.) And ...., I agree that developing the DHCP server-to-server protocol on top of the SCSP capabilities is a good thing to do. I'm currently working up a draft to send out to the group. Thanks, Bob   Received: from cnri by ietf.org id aa18720; 25 Feb 97 21:42 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa28626; 25 Feb 97 21:42 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AC11303; Tue, 25 Feb 1997 21:37:49 -0500 Date: Tue, 25 Feb 1997 21:37:49 -0500 Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Agenda for Memphis IETF X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 It's time to put together an agenda for the DHC WG meeting in Memphis. Please forward your suggestions for agenda items - I'll collect them and publish a final agenda in a few days. - Ralph   Received: from cnri by ietf.org id aa29505; 26 Feb 97 0:45 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa02115; 26 Feb 97 0:45 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB04401; Wed, 26 Feb 1997 00:41:48 -0500 Date: Wed, 26 Feb 1997 00:41:48 -0500 Message-Id: <199702260509.VAA00556@andare.fugue.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Agenda for Memphis IETF X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > It's time to put together an agenda for the DHC WG meeting in Memphis. > Please forward your suggestions for agenda items - I'll collect them and > publish a final agenda in a few days. I'd really like to see some discussion on the Server-to-Server protocol. _MelloN_   Received: from cnri by ietf.org id aa22753; 26 Feb 97 18:41 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa29137; 26 Feb 97 18:40 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB16972; Wed, 26 Feb 1997 18:35:47 -0500 Date: Wed, 26 Feb 1997 18:35:47 -0500 Message-Id: <3.0.32.19970226101114.0069aca0@qsun.att.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Robert G. Cole" To: Multiple recipients of list Subject: Re: Agenda for Memphis IETF X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Pro Version 3.0 (32) Ralph, If you want , I would b glad to go over the SCSP capabilities and DHCP riding on top of it? Bob BTW, what days and time slots do you have? At 09:37 PM 2/25/97 -0500, you wrote: >It's time to put together an agenda for the DHC WG meeting in Memphis. >Please forward your suggestions for agenda items - I'll collect them and >publish a final agenda in a few days. > >- Ralph > > > > > >   Received: from cnri by ietf.org id aa16957; 27 Feb 97 17:49 EST Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa25279; 27 Feb 97 17:49 EST Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA26679; Thu, 27 Feb 1997 17:46:08 -0500 Date: Thu, 27 Feb 1997 17:46:08 -0500 Message-Id: <9702271858.AA14086@gw3.pacbell.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Hibbs, R Barr (rbhibbs)" To: Multiple recipients of list Subject: RE: Agenda for Memphis IETF X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Worldtalk (NetConnex V4.00a)/MIME I'd really like in-depth discussion (maybe several shorter sessions) on the server-to-server and DHCP-to-DNS protocols --Barr Hibbs Pacific*Bell 370 Third Street, Room 207 San Francisco, CA 94107-1279 +1(415)-545-1576 rbhibbs@pacbell.com ---------- From: dhcp-v4 To: Multiple recipients of list Subject: Agenda for Memphis IETF Date: Wednesday, February 26, 1997 9:23AM It's time to put together an agenda for the DHC WG meeting in Memphis. Please forward your suggestions for agenda items - I'll collect them and publish a final agenda in a few days. - Ralph