Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08420; 1 Sep 95 9:04 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08416; 1 Sep 95 9:04 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa09264; 1 Sep 95 9:04 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA01388; Fri, 1 Sep 1995 08:57:43 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA01567; Fri, 1 Sep 1995 08:57:12 -0400 Received: from mailbox.syr.edu by sol (5.x/SMI-SVR4) id AA02317; Fri, 1 Sep 1995 08:57:02 -0400 Received: from forbin.syr.edu (jmwobus@forbin.syr.edu [128.230.1.9]) by mailbox.syr.edu (8.6.9/8.6.9) with SMTP id HAA02511 for ; Fri, 1 Sep 1995 07:01:04 -0400 Received: by forbin.syr.edu (5.x/Spike-2.0) id AA28396; Fri, 1 Sep 1995 06:56:34 -0400 Message-Id: <9509011056.AA28396@forbin.syr.edu> To: host-conf@sol.eg.bucknell.edu Subject: DHCP FAQ Memo Date: Fri, 01 Sep 1995 06:56:33 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "John M. Wobus" DHCP FAQ Author John Wobus, jmwobus@syr.edu (corrections welcome) Date 8/15/1995 This file http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html Questions 1. General 1. What is DHCP? 2. What is DHCP's purpose? 3. How is it different that BOOTP or RARP? 4. Why shouldn't clients assign IP numbers without the use of a server? 5. Can DHCP support statically defined addresses? 6. Can a BOOTP client boot from a DHCP server? 7. Can a DHCP client boot from a BOOTP server? 8. Can a DHCP client update its DNS entry through DHCP? 9. When will the server to server protocol be defined? 10. Is there a DHCP mailing list? 11. In a subnetted environment, how does the DHCP server discover what subnet a request has come from? 12. Where is DHCP defined? 13. Can DHCP support remote access? 14. What are the Gotcha's? 2. Info on Implementations 1. What freeware DHCP servers are available? 2. What commercial DHCP servers are available? 3. Which vendors of client software currently support DHCP? 4. What are the DHCP plans of major client-software vendors? 5. What Routers forward DHCP requests? 6. Which implementations support or require the broadcast flag? Answers 1. General 1. What is DHCP? DHCP stands for "Dynamic Host Configuration Protocol". 2. What is DHCP's purpose? DHCP's purpose is to enable individual computers on an IP network to extract their configurations from a server (the 'DHCP server') or servers, in particular, servers that have no exact information about the individual computers until they request the information. The overall purpose of this is to reduce the work necessary to administer a large IP network. 3. How is it different that BOOTP or RARP? DHCP is based on BOOTP and maintains some backward compatibility. The main difference is that BOOTP was designed for manual pre-configuration of the host information in a server database, while DHCP allows for dynamic allocation of network addresses and configurations to newly attached hosts. Additionally, DHCP allows for recovery and reallocation of network addresses through a leasing mechanism. RARP is a protocol used by Sun and other vendors that allows a computer to find out its own IP number, which is one of the protocol parameters typically passed to the client system by DHCP or BOOTP. RARP doesn't support other parameters and using it, a server can only serve a single LAN. DHCP and BOOTP are designed so they can be routed. 4. Why shouldn't clients assign IP numbers without the use of a server? It is theoretically possible for client-machines to find addresses to use by picking an address out of the blue and broadcasting a request of all the other client machines to see if they are using them. Appletalk is designed around this idea, and Apple's MacTCP can be configured to do this for IP. However, this method of IP address assignment has disadvantages. 1. A computer that needs a permanently-assigned IP number might be turned off and lose its number to a machine coming up. This has problems both for finding services and for security. 2. A network might be temporarily divided into two non-communicating networks while a network component is not functioning. During this time, two different client-machines might end up claiming the same IP number. When the network comes back, they start malfunctioning. 3. If such dynamic assignment is to be confined to ranges of IP addresses, then the ranges are configured in each desktop machine rather than being centrally administered. This can lead both to hidden configuration errors and to difficulty in changing the range. Another problem with the use of such ranges is keeping it easy to move a computer from one subnet to another. 5. Can DHCP support statically defined addresses? Yes. At least there is nothing in the protocol to preclude this and one expects it to be a feature of any DHCP server. This is really a server matter and the client should work either way. 6. Can a BOOTP client boot from a DHCP server? A DHCP server can be written this way. Since DHCP was developed after BOOTP, it would be logical for most server developers to support this. 7. Can a DHCP client boot from a BOOTP server? A DHCP client can be written this way, i.e. to treat a BOOTP reply as an unending lease on the IP address. 8. Can a DHCP client update its DNS entry through DHCP? There are options in DHCP through which a DHCP client can request that its DNS entry be updated. DHCP clients will be able to take advantage of planned enhancements to the DNS protocol that will allow dynamic updates through the network. (Note: as far as I can tell, the DNS needs no protocol update since the server already tells the clients how long they can use the information they receive; what is really needed is a DNS server that can make fuller use of this feature and that cooperates with a DHCP server, perhaps through the use of some new "DHCP-server-to-DNS-server" protocol). 9. When will the server to server protocol be defined? The DHC WG of the IETF is actively investigating the issues in inter-server communication. The protocol should be defined "soon". 10. Is there a DHCP mailing list? There are several: List Purpose ---- ------- host-conf@sol.eg.bucknell.edu General discussion dhcp-bake@bucknell.edu DHCP bakeoffs dhcp-impl@bucknell.edu Implementations dhcp-serve@bucknell.edu Server to server protocol Admin requests for the host-conf list should go to host-conf-request@sol.eg.bucknell.edu; admin requests for the other lists should go to listserv@bucknell.edu. 11. In a subnetted environment, how does the DHCP server discover what subnet a request has come from? DHCP client messages are sent to off-net servers by DHCP relay agents, which are often a part of an IP router. The DHCP relay agent records the subnet from which the message was received in the DHCP message header for use by the DHCP server. 12. Where is DHCP defined? In Internet RFCs. RFC1541 R. Droms, "Dynamic Host Configuration Protocol", 10/27/1993. RFC1534 R. Droms, "Interoperation Between DHCP and BOOTP", 10/08/1993. RFC1533 S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor Extensions", 10/08/1993. 13. Can DHCP support remote access? PPP has its own non-DHCP way in which communications servers can hand clients an IP address called IPCP (IP Control Protocol) but doesn't have the same flexibility as DHCP or BOOTP in handing out other parameters. Such a communications server may support the use of DHCP to acquire the IP addresses it gives out. This is sometimes called doing DHCP by proxy for the client. I know that Windows NT's remote access support does this. A feature of DHCP under development (DHCPinform) is a method by which a DHCP server can supply parameters to a client that already has an IP number. With this, a PPP client could get its IP number using IPCP, then get the rest of its parameters using this feature of DHCP. SLIP has no standard way in which a server can hand a client an IP address, but many communications servers support non-standard ways of doing this that can be utilized by scripts, etc. Thus, like communications servers supporting PPP, such communications servers could also support the use of DHCP to acquire the IP addressees to give out. I am not currently aware of any way in which DHCP can support client-computers served solely by PPP or SLIP. Such a computer doesn't have the IEEE-style MAC address that DHCP requires to act as its key to determining which client-computer is which within the same subnet. Communications servers that acquire IP numbers for their clients via DHCP run into the same roadblock in that they have just one MAC address, but need to acquire more than one IP address. One way such a communications server can get around this problem is through the use of a set of unique pseudo-MAC addresses for the purposes of its communications with the DHCP server. 14. What are the Gotcha's? o Someone suggested to me that a malicious user could make trouble by putting up an unofficial DHCP server. The main problem I can see is the potential for two or more "innocent bystander" nodes ending up with the same IP number. Net result is problems using the nodes, possibly intermittent of one or the other is sometimes turned off. o The "broadcast flag": DHCP includes a way in which client implementations unable to receive a packet with a specific IP address can ask the server or relay agent to use the broadcast IP address in the replies (a "flag" set by the client in the requests). The definition of DHCP states that implementations "should" honor this flag, but it doesn't say they "must". Some Microsoft TCP/IP implementations used this flag, which meant in practical terms, relay agents and servers had to implement it. A number of BOOTP-relay-agent implementations (e.g. in routers) handled DHCP just fine except for the need for this feature, thus they announced new versions stated to handle DHCP. o Some of the virtual LAN schemes, i.e., those that use the packet's IP number to decide which "virtual LAN" a client-computer is on for the purposes of TCP/IP, don't work when using DHCP to dynamically assign addresses. DHCP servers and relay agents use their knowledge of what LAN the client-station is on to select the subnet number for the client-station's new IP address whereas such switches use the subnet number sent by the client-station to decide which (virtual) LAN to put the station on. o There have been servers that are inflexible as to the list of configuration parameters they were able to serve. If your client requires certain parameters, you could find such a server unusable. o I hate to cast wide suspicions, but I've heard occasional word on client DHCP implementations that do not implement the entire protocol. Doing so requires that the software module be able to wake up again after a specified period of time and "renew the lease", i.e., ask to continue using the IP number. This is at least one feature of DHCP that is very hard to implement in some simpler systems. o The knowledge that a particular IP number is associated with a particular node is often used for various functions. Examples are: for security purposes, for network management, and even for identifying resources. Furthermore, if the DNS's names are going to identify IP numbers, the numbers, the IP numbers have to be stable. Dynamic configuration of the IP numbers undercuts such methods. For this reason, some sites try to keep the continued use of dynamically allocatable IP numbers to a minimum. o There are a number of issues regarding the patched bootp servers. These have been reported to re DD2.4.3: # 'When run from inetd, I had problems with "Could not bind port" and DHCP request failure. I don't know why, and the problem went away when bootpd is run as a daemon.' # 'Unless you set "dl" to some value in the bootptab file, the DHCP lease time, renewal time and prebinding time will be rubbish, which will cause occasional renewal problems.' 2. Info on Implementations 1. What freeware DHCP servers are available? (This is not necessarily a complete list) 950415 Bootp server: Bootp 2.4.3 (not DHCP, but with the "DHCP patches" mentioned below, can handle DHCP requests) ftp://ftp.mc.com/pub/bootp-2.4.3.tar.Z 950425 Bootp server version 2.4.3 with "samba" DHCP patches (does static allocation of IP addresses) http://www.sghms.ac.uk/~mpreston/bootp_dhcp.tar.Z (within http://www.sghms.ac.uk/~mpreston/tools.htm") 950630 WIDE Project: Akihiro Tominaga (tomy@sfc.wide.ad.jp) WIDE Project Keio Univ. Japan ftp://sh.wide.ad.jp/WIDE/free-ware/dhcp/dhcp-1.2.1.tar.gz Check Archie for dhcp-1.2.1 because lots of sites distribute it. 950706 "samba" DHCP patches for bootp server: (does static allocation of IP addresses) ftp://nimbus.anu.edu.au:/pub/tridge/samba/contributed/DHCP.patch (note: I've heard that the patched server will crash if it receives one particular optional packet, the DHCP Release packet) 950711 Patched bootp server supporting DHCP-based "automatic" allocation: (gives addresses dynamically, but never takes them away) ftp://ftp.ntplx.net/pub/networking/bootp/bootp-DD2.4.3.tar.gz 2. What commercial DHCP servers are available? (This is not necessarily a complete list) 950425 Silicon Graphics 950613 NetWare/IP 2.1 will NOT support DHCP but support for enhanced bootp will be provided. I'm guessing this means DHCP-format packets, but no address leasing. 950713 James Drews (drews@engr.wisc.edu) of U Wisconsin is working on an NLM which he plans to sell commercially. 950714 FTP Software (Services OnNet Product) http://www.ftp.com/mkt_info/services.html 950714 Sun (SolarNet) http://www.sun.com/cgi-bin/show?sunsoft/Products/Networking-products/pro ducts/pcadmin.html 950714 Microsoft Windows NT http://www.microsoft.com/NTServer/ http://www.microsoft.com/BackOffice/techbriefs/tech1000.htm 950714 Hewlett Packard HP-UX 950714 TGV: next major release of Multinet for VMS 950802 Process Software: server for OpenVMS http://www.process.com/ 950814 Competitive Automation(415-321-4006): SunOS4.x, Solaris2.x and DECOSF3.x,4.x servers 3. Which vendors of client software currently support DHCP? (This is not necessarily a complete list) 950417 Shiva: proxy client for remote users (in Lanrovers and Netmodems) 950419 Dirk Koeppen EDV-Beratungs-GmbH: TCP/IP DHCP Boot ROMs (TCP/IP BOOT-PROM) 950421 Microsoft: Windows for Workgroups 950425 Sun 950425 Silicon Graphics 950425 Hewlett-Packard 950502 NetManage: Chameleon 4.5 950630 Beame & Whiteside Software: resells Dirk Koeppen EDV-Beratungs-GmbH's TCP/IP BOOT-PROM 950705 Microsoft: MS-TCP/IP 3.11a & MS-TCP/IP 3.11b 950711 Microsoft: Windows NT 3.5 950711 Microsoft: Windows for Workgroups 3.11a 950711 Frontier Technologies(800-929-3054): in SuperTCP for Windows http:www.frontiertech.com info@frontiertech.com 950712 Beame & Whiteside(800-720-7151): BW-Connect NFS for DOS & Windows 950726 TGV: next release of Multinet for Windows (beyond V3.3) 950725 IBM: a future release of AIX 950728 Sun: PCNFS for Windows 950801 FTP Software: for DOS and Windows (included in PC/TCP OnNet and PC/TCP networking software; note: the DOS client utilizes DHCP queries/responses to get an IP address, but does not track its lease and renew when it should; however, the Windows client is true DHCP. FTP has stated that the DHCP client the upcoming OnNet 2.0 and PC/TCP 4.0 releases will perform lease renewal properly). http://www.ftp.com/ 950802 Wollongong: PathWay Access ver 3.2 (Windows) http://www.twg.com/ 950802 WRQ: Reflection Network Series products (version 5) for Windows http://www.wrq.com/ 950814 Competitive Automation(415-321-4006): SunOS4.x, Solaris2.x and DECOSF3.x,4.x clients 4. What are the DHCP plans of major client-software vendors? Apple MacTCP MacTCP's successor, Open Transport, supports DHCP. As of 7/5/95, Open Trasnport is included with the Macintosh 9500. Version 1.1 of Open Transport will ship as a separate product very soon (8/95 is a good guess). Microsoft Windows95 will support it and will not support BOOTP. Novell LAN Workplace for DOS has plans for client support later in 1995. IBM OS/2 will support it; I have no news on when or what version. 5. What Routers forward DHCP requests? (This is not necessarily a complete list). Note that in general, these routers probably already had BOOTP forwarding, but lacked the support for the BOOTP broadcast flag (see "broadcast flag" under What are the Gotcha's? above). Cisco (from Cisco FAQ) Routers running GSYS version 9.21(4) and 10.0(3) as well as later releases. Wellfleet/Bay (from Wellfleet FAQ) DHCP is supported by enabling BOOTP support (with transmission and/or reception as needed). 3Com Netbuilder Version 7.2 software can support DHCP relaying through the use of its generic UDP Helper service. Version 8.0 and later officially supports DHCP. Xyplex Word is that release 5.1 slated for first quarter 1996 will support it. 6. Which implementations support or require the broadcast flag? The broadcast flag is an optional element of DHCP, but a client which sets it works only with a server or relay that supports it. o Clients Microsoft Windows NT DHCP client support added with version 3.5 sets the broadcast flag. Version 3.51 and later no longer set it. The exception is in the remote access support: it sets the flag when it uses DHCP to acquire addresses to hand out to its PPP clients. tcp/ip-32 for Microsoft Windows for Workgroups (WFW) Version 3.11a sets it, but version 3.11B doesn't. Microsoft Windows 95 Does not set the broadcast flag.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08489; 1 Sep 95 9:07 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08485; 1 Sep 95 9:07 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa09331; 1 Sep 95 9:07 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA02157; Fri, 1 Sep 1995 09:02:04 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA01660; Fri, 1 Sep 1995 09:01:27 -0400 Received: from VNET.IBM.COM by sol (5.x/SMI-SVR4) id AA02336; Fri, 1 Sep 1995 09:01:19 -0400 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7372; Fri, 01 Sep 95 09:01:05 EDT Received: by RTP (XAGENTA 4.0) id 8704; Fri, 1 Sep 1995 09:00:32 -0400 Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA19071; Fri, 1 Sep 1995 09:00:44 -0400 Message-Id: <9509011300.AA19071@cichlid.raleigh.ibm.com> To: bound@zk3.dec.com Cc: host-conf@sol.eg.bucknell.edu Subject: Re: Big DHCPv6 packets (UDP vs. TCP) In-Reply-To: (Your message of Thu, 31 Aug 95 22:07:49 D.) <9509010207.AA21196@xirtlu.zk3.dec.com> Date: Fri, 01 Sep 95 09:00:42 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Narten >Once the client has the server address its client to server. Then TCP >will do quite well for the type of transaction we are doing. We don't >have to worry about the entire request/response model and whether the >other node actually finished the transaction. This is why two other >implementors I spoke with agreed this was a move in the right direction. I'm not saying TCP won't work, it certainly will. What I am suggesting is that it is the "easy" way of dealing with the need for fragmentation. And by "easy", I mean easy for implementors. At the same time, the overhead (delay, number of packets) of typical exchanges (in which multiple addresses need to be configuried) will be higher than it probably needs to be. >I would never have suggested it just because of UDP (pmtu disc and end-to-end >fragmentation). But I will say that it is messy with UDP applications >and I guess is another benefit to TCP. It *can* be messy, but isn't necessarily so. It depends entirely on the details of the DHCPv6 protocol. >>In practice, I'd expect DHCP to >>be used mostly in LAN environments where 1500 byte paths/buffers are >>the norm. >But thats not the case. I thought this too when I started working on >DHCPv6. But the case is that most folks use relay-agents until the >servers address is known and then the requests are going to a remote >server. This is why TCP will give us better service. And also folks >run redundant servers, which our draft will support. Even if the DHCP server itself is remote, I'd bet that it will not be remote in the "behind a WAN" sense. In the vast majority of cases, clients and servers will be separated only by LANs, where 1500 byte path length/buffers will be the norm. Does anyone disagree with this assertion? >>I don't think building a UDP-based protocol that does >>fragmentation would be that hard or complicated. We're not trying to >>handle JUMBOGRAMS here after all. >Its complex when applications have to have knowledge of the networks >limitations. If its done in UDP transparently you have just added >overhead to UDP and so from a performance perspective your not going to >gain anything over TCP in an order of magnitude. The above performance statement cannot be made without looking at the details of the protocols being considered. If the client-server protocol is stateful on both ends, TCP would probably be justified (e.g., the UDP-based protocol would essentially reinvent TCP's existing mechanisms). However, if the model is simple request/reply transactions (that are idempotent as well), I'm not convinced TCP is justified. But it depends on the details, which we don't have in front of us. Here is another way of looking at it. Suppose we could assume packets were big enough that fragmentation would never be necessary. We then look at the application protocol and conclude that UDP was perfectly adequate and TCP was overkill. If this is the case, I assert that just adding support for fragmentation (above UDP) could be done easily enough to still justify the use of UDP over TCP. To get around the PMTU problem, it might simply be wise to always send out packets that are 576 bytes in size and then fragment as necessary. That is, not even try to take advantage of the actual PMTU size. In the time it takes to figure out what the optimal PMTU is, we could already have just sent (small) fragments and completed the transaction. >We have had some of this discussion and I think TCP will in fact work >and work well. In your response I did not hear anything frightening to >the network or implementations if we do use TCP. All I'm saying is that I'm not convinced that TCP is necessary. But it sounds like there is still flexibility about whether TCP will be in the final spec, and that sounds good to me at this point. Thomas   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08544; 1 Sep 95 9:12 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08540; 1 Sep 95 9:12 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa09420; 1 Sep 95 9:12 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA02672; Fri, 1 Sep 1995 09:05:05 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA01727; Fri, 1 Sep 1995 09:04:20 -0400 Received: from mailbox.syr.edu by sol (5.x/SMI-SVR4) id AA02354; Fri, 1 Sep 1995 09:04:12 -0400 Received: from spider.syr.edu (jmwobus@spider.syr.edu [128.230.4.42]) by mailbox.syr.edu (8.6.9/8.6.9) with SMTP id JAA13073; Fri, 1 Sep 1995 09:08:10 -0400 Received: by spider.syr.edu (5.x/Spike-2.0) id AA06596; Fri, 1 Sep 1995 09:03:35 -0400 Message-Id: <9509011303.AA06596@spider.syr.edu> To: host-conf@sol.eg.bucknell.edu Cc: Dikran Kassabian Subject: Re: dhcp/bootp servers In-Reply-To: Your message of "Mon, 21 Aug 1995 16:19:03 EDT." <9508212021.AA28632@staff.dccs.upenn.edu> Date: Fri, 01 Sep 1995 09:03:34 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "John M. Wobus" In message <9508212021.AA28632@staff.dccs.upenn.edu>, Dikran Kassabian writes: >One promising looking distribution is referenced in the above URL: > >950711 Patched bootp server supporting DHCP-based "automatic" allocation: > (gives addresses dynamically, but never takes them away) > ftp://ftp.ntplx.net/pub/networking/bootp/bootp-DD2.4.3.tar.gz > >The author is Andrew Lindh . Some of the notes are >confusing, but perhaps this one will be a good starting point. Has >anyone (other than the author) on this mailing list used it successfully >for the kinds of things I want to do? We are in a position like you and just started trying this server. Our experience with the patched bootpd so far: -(this change relates to the version of bootpd rather than the dhcp-related mods) The syntax of the bootp configuration file is different from the version of bootpd that we were running: it requires 0x in front of the data portion of hex fields that don't start with 0 (e.g. haddr=0xaaxx00aa11); also, it requires a period (.) at the beginning of any label that is not a hostname, i.e. is used in "tc=" constructs. Both these were changes in the rules rather than tightening of the rules: our modified config file would not work with our older bootpd. -The patch included no documentation explaining exactly what new parameters are required to run DHCP, or how one configures IP addresses that will be handed out to new clients, or how the Ethernet addresses of new clients are "remembered". I assumed that when the daemon was run with a straight bootp configuration that it would respond to DHCP requests for any mac addresses that were preconfigured for use with bootp. -We successfully brought up Windows 95 with it. That is the good news. It logged that it could not fit all the parameters in the packet and left out one (our ntp server). In the past, we just sent nearly every globally-relevant parameter that anyone could use to everyone. I suspect we'll have to revise that policy. -Windows 95 has a button to renew the lease. Upon clicking it, Windows 95 did NOT indicate that the renewal was successful. Bootpd did log the same problem (could not fit all paramemters), thus suggesting that it got the packet and did something with it. -When I took the bootpd down from our SunOS machine after testing (using the ever-popular "kill -9" method), I ran into a lingering problem that is beyond my competence: as far as I could tell, the machine could no longer send IP packets to its own IP number (until I rebooted it). It could communicate with other IP addresses on its own subnet, network, and the Internet, as well as 127.0.0.1, but not its own. A check of netstat, netstat -r, and ipconfig revealed nothing that changed from before I ran the daemon to after I ran the daemon. And that is as far as we got. I'm hoping to come up with enough time to see if the old bootpd trashes SunOS under the same circumstances, study the code to see how the old bootpd and the new bootpd handle their sockets, or NIT or whatever differently (assuming the older one works fine), use a Sniffer(TM) to watch the "renew lease" interaction, figure out how to rearrange our bootp file to get around the packet-size-related problem, post messages on groups like comp.protocols.tcp-ip and info.sun-managers about what might have happened to our SunOS system, and write that programmer. -John Wobus   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00383; 3 Sep 95 23:18 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00379; 3 Sep 95 23:18 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa00715; 3 Sep 95 23:18 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA13627; Sun, 3 Sep 1995 23:04:43 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA11283; Sun, 3 Sep 1995 23:00:49 -0400 Received: from coral.bucknell.edu by sol (5.x/SMI-SVR4) id AA03882; Sun, 3 Sep 1995 23:00:45 -0400 Received: from uvite57.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA12906; Sun, 3 Sep 1995 22:57:49 -0400 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 3 Sep 1995 22:57:56 -0400 To: Thomas Narten , bound@zk3.dec.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Re: Big DHCPv6 packets (UDP vs. TCP) Cc: host-conf@sol.eg.bucknell.edu At 9:00 AM 9/1/95, Thomas Narten wrote: >>Its complex when applications have to have knowledge of the networks >>limitations. If its done in UDP transparently you have just added >>overhead to UDP and so from a performance perspective your not going to >>gain anything over TCP in an order of magnitude. > >The above performance statement cannot be made without looking at the >details of the protocols being considered. If the client-server >protocol is stateful on both ends, TCP would probably be justified >(e.g., the UDP-based protocol would essentially reinvent TCP's >existing mechanisms). However, if the model is simple request/reply >transactions (that are idempotent as well), I'm not convinced TCP is >justified. But it depends on the details, which we don't have in front >of us. > >Here is another way of looking at it. Suppose we could assume packets >were big enough that fragmentation would never be necessary. We then >look at the application protocol and conclude that UDP was perfectly >adequate and TCP was overkill. If this is the case, I assert that just >adding support for fragmentation (above UDP) could be done easily >enough to still justify the use of UDP over TCP. > >To get around the PMTU problem, it might simply be wise to always send >out packets that are 576 bytes in size and then fragment as >necessary. That is, not even try to take advantage of the actual PMTU >size. In the time it takes to figure out what the optimal PMTU is, we >could already have just sent (small) fragments and completed the >transaction. I think Thomas has articulated my instinctive reaction to the proposal to use TCP for some DHCP transactions. I have always thought of DHCP as request/reply protocol that fits closely with the UDP model. In my head, I know that TCP doesn't really add significant overhead and takes avantage of PMTU as well as other reliaiblity mechanisms. But, I stil feel that, somehow, if we need to use TCP to solve a problem, then we're solving the wrong problem. Do we have data that indicates a fixed 576-octet limit is a show-stopper for DHCP? BTW - talking about solving problems: Could SNMP be used to solve the renumbering/revaliation problem? We've never seriously explored the boundary between DHCP and SNMP (not to mention a service location protocol). Right now, we're pushing DHCP to send lots of configuration information an handle many administrtative tasks. What happens if we try to turn the know back the other way and look at DHCP as a minimal bootstrap mechanism that does just enough to allow SNMP to take over? So, for example, suppose we add a "REVALIDATE DHCP" flag to the host MIB. Setting that flag forces the host to use DHCP to revalidate its network parameters. Of course, if we were real brave, we'd simply allow SNMP to change the host's interface prefix/address on the fly. But that sort of reminds me of using adb to change parameters in a running UNIX kernel without notifying the users. The potential for disaster (worst case, unrecoverable errer) seems pretty high... - Ralph   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11127; 5 Sep 95 10:00 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11123; 5 Sep 95 10:00 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa10328; 5 Sep 95 10:00 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA17712; Tue, 5 Sep 1995 09:52:06 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA01923; Tue, 5 Sep 1995 09:25:38 -0400 Received: from mail2.digital.com by sol (5.x/SMI-SVR4) id AA04506; Tue, 5 Sep 1995 02:05:44 -0400 Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA26154; Mon, 4 Sep 1995 22:56:32 -0700 Received: by xirtlu.zk3.dec.com; id AA13331; Tue, 5 Sep 1995 01:56:28 -0400 Message-Id: <9509050556.AA13331@xirtlu.zk3.dec.com> To: Ralph Droms Cc: Thomas Narten , bound@zk3.dec.com, host-conf@sol.eg.bucknell.edu Subject: Re: Big DHCPv6 packets (UDP vs. TCP) In-Reply-To: Your message of "Sun, 03 Sep 95 22:57:56 EDT." Date: Tue, 05 Sep 95 01:56:22 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bound@zk3.dec.com X-Mts: smtp >I think Thomas has articulated my instinctive reaction to the proposal to >use TCP for some DHCP transactions. I have always thought of DHCP as >request/reply protocol that fits closely with the UDP model. In my head, I >know that TCP doesn't really add significant overhead and takes avantage of >PMTU as well as other reliaiblity mechanisms. But, I stil feel that, >somehow, if we need to use TCP to solve a problem, then we're solving the >wrong problem. In my mind there are two issues to discuss (others ??): #1. DHCPv6 is transaction based and needs reliability. #2. DHCPv6 presents new problems because of the IPv6 PMTU/Fragmentation model. My reasons for proposing TCP is #1 and #2 is only a benefit. So I would like to make sure the WG agrees that #1 is important. Here is my logic. Regarding #1. I think DHCP has evolved past a request/response model in IPv6 because its very important to coordinate DNS, Addresses, and Renumbering in the model for IPv6 DHCP. This IMHO means that "reliability" is critical. This IMHO elevates DHCP to a transaction based protocol that requires reliability beyond what can be obtained by a request/response protocol. If we build this reliability over UDP we are reinventing TCP reliability at the application layer. I do not think this is a good approach. What I can do is show how TCP can be used for DHCPv6 and see if the WG sees any merit in this strategy. It will perform no less than a request/response model over UDP, and will give a much higher gurantee that the transaction completed in a valid state, which is critical for DHCPv6. Regarding #2 PMTU for UDP can be implemented in various ways. We cannot state how that must be done for DHCPv6. I would never give ISV vendors a system where they had to care about the underlying network. So for me the issue is what I must do in the kernel and what happens before I pass data back to the socket-layer PCBs. Now this has been done anyway in several implementations within UDP-IPv4 and fragmentation will take place transparent to the application. But, to avoid "consistent" fragmentation where the applications send buffer is 8K and the PMTU across the network is at 1K, that application packets generally will consistently have to fragment end-to-end in IPv6 on each send. The objective in IPv6 IMHO is to eliminate all fragmentation and even end-to-end is considered evil. I agree fyi that its evil too. To avoid this an application would have to reduce its send buffer at some point, or put all the mechanisms in UDP that TCP has today such as the MSS and Window concepts to avoid the fragmentation. No one is going to do that without a serious change to the UDP protocol IMHO. If we do not use TCP then the present wording in the present spec suffices IMHO to solve the problem. Simply that an implementation should use the PMTU and Fragmentation model that exists in IPv6. No more needs to be stated. >Do we have data that indicates a fixed 576-octet limit is a show-stopper >for DHCP? I have attached a memo from Fred Lien at Boeing as one data point to the list awhile ago. Addresses in IPv6 are 16bytes as we all know and that makes the packets bigger. Anyone else on the list care to comment per their experiences? I am convinced that most implementations use servers for multiple subnets as this is cost effective and traffic for DHCP moves across routers and through networks even for DHCPv4 today. This makes sense to me too. In IPv6 you cannot be guranteed that packets > 556 will get across the network without using PMTU Discovery. I believe that 2 years from now the majority of client packets will go across routers and networks. This is true where I work now and at Microsoft and other private companies I deal with as customers. Its just cost effective to maintain servers for multiple subnets (in IPv6 that is multiple links). >BTW - talking about solving problems: Could SNMP be used to solve the >renumbering/revaliation problem? We've never seriously explored the >boundary between DHCP and SNMP (not to mention a service location >protocol). Right now, we're pushing DHCP to send lots of configuration >information an handle many administrtative tasks. What happens if we try >to turn the know back the other way and look at DHCP as a minimal bootstrap >mechanism that does just enough to allow SNMP to take over? >So, for example, suppose we add a "REVALIDATE DHCP" flag to the host MIB. >Setting that flag forces the host to use DHCP to revalidate its network >parameters. Well I view DHCPv6 as one method to get addresses and provide other functions (e.g. DNS Updates). I view the implementation of IPv6 to have the know-how to know when its addresses expire, based on data provided by an address lifetime set. Having done this I don't see the benefit? Its a check that must be done when a timer expires as part of an if-addr structure when the deprecation or validation timers expire. Not sure of any added-value from SNMP MIB being set? >Of course, if we were real brave, we'd simply allow SNMP to change the >host's interface prefix/address on the fly. But that sort of reminds me of >using adb to change parameters in a running UNIX kernel without notifying >the users. The potential for disaster (worst case, unrecoverable errer) >seems pretty high... I agree. I also have had it said to me that we often treat SNMP as bad as we treat DNS as our database dumping ground and its the assembler language of the IETF when all other high-level programming strategies fail. I view SNMP as a reporting function not an action function as a protocol. DHCP is an action protocol and less of a reporting protocol. thanks /jim ------------------------------ Return-Path: fred@speedster.ca.boeing.com Received: from decvax.zk3.dec.com by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA21951; Tue, 16 May 1995 14:59:48 -0400 Received: from sol.eg.bucknell.edu by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA12981; Tue, 16 May 1995 14:59:34 -0400 Received: from atc.boeing.com by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Tue, 16 May 95 14:07:42 EDT Received: by atc.boeing.com (5.57) id AA27156; Tue, 16 May 95 11:15:36 -0700 Received: by speedster.ca.boeing.com (5.64/A/UX-2.00) id AA01637; Tue, 16 May 95 11:10:20 PDT Date: Tue, 16 May 95 11:10:20 PDT From: fred@speedster.ca.boeing.com (Fred Lien) Reply-To: fred@speedster.ca.boeing.com Message-Id: <9505161810.AA01637@speedster.ca.boeing.com> To: host-conf@speedster.ca.boeing.com Jim Currently, our DHCP server returns the following options fields to the pc client: Subnet mask: 4 bytes Gateway: 4 bytes 2 dns servers: 8 bytes 2 nbns servers: 8 bytes 2 nbds servers: 8 bytes lease duration: 4 bytes nb nodetype: 1 byte domain name: ~16 to 20 bytes scope name: 0 bytes broadcast addr: 4 bytes Vendor specific options: 2 ldap server addresses: 8 bytes username: ~20 bytes phone: 10 bytes building/floor: 10 bytes location: 6 bytes inventory number: 7 bytes building list: ~5 to 20 bytes universal ldap id: 7 bytes nbns=net bios name server nbds=net bios datagram server ldap=light directory access protocol, a number which really deserves it's own tag value... scope=netbios scope building list=a set of possible buildings that a given subnet spans Note: obviously, the address values will be different for ipv6, due to a different address length. You can do the math, I'm not sure what the numbers are (hint: I do know it involves algebra!)... Also, don't forget that each of the above lines has a 2 byte overhead. The username the client sends to the server is returned to the client in case the server has to do some post-processing before the client program stores it away. Same with the phone, building/floor, location, and inventory number. The bottom line is, we use about 2/3rds of the available options field, and haven't had to use the overloaded fields. This would not be a great idea anyway, since some of the bootp clients supported use a bootfile "hint" name in the bootfile field to identify themselves. Fred Lien   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19049; 8 Sep 95 14:24 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19045; 8 Sep 95 14:24 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa13569; 8 Sep 95 14:24 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA01534; Fri, 8 Sep 1995 14:12:47 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA09100; Fri, 8 Sep 1995 14:10:58 -0400 Received: from coral.bucknell.edu by sol (5.x/SMI-SVR4) id AA00230; Fri, 8 Sep 1995 14:10:45 -0400 Received: from droms.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA00995; Fri, 8 Sep 1995 14:10:36 -0400 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Sep 1995 14:10:46 -0400 To: host-conf@sol.eg.bucknell.edu, addrconf@cisco.com, ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: New mailing list for discussion of DHCPv6 In a conversation with Jim Bound this morning, we thought it might be a good idea to provide a separate mailing list for the discussion of DHCPv6. Noting the lack of participation in discussion of DHCPv6 on the host-conf mailing list, it seemed to us that we might encourage discussion on the part of the IPv6 community by separating DHCPv4 from DHCPv6. So, I've set up a new list called dhcp-v6@bucknell.edu for discussion of the DHCPv6 protocol spec. Note that this list will *not* be gatewayed to the host-conf list; the primary raison d'etre for the new list is to separate mail about DHCPv4 from mail about DHCPv6. Please direct subscription requests to listserv@bucknell.edu. - Ralph   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00620; 9 Sep 95 12:34 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00616; 9 Sep 95 12:34 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa06014; 9 Sep 95 12:34 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA17568; Sat, 9 Sep 1995 12:28:49 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA15523; Sat, 9 Sep 1995 12:25:10 -0400 Received: from shiva2.cac.washington.edu by sol (5.x/SMI-SVR4) id AA00961; Sat, 9 Sep 1995 12:25:03 -0400 Received: by shiva2.cac.washington.edu (5.65+UW95.08/UW-NDC Revision: 2.33 ) id AA11361; Sat, 9 Sep 95 09:24:47 -0700 Date: Sat, 9 Sep 1995 09:24:44 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Carlson To: bound@zk3.dec.com Cc: host-conf@sol.eg.bucknell.edu Subject: Re: UDP/TCP in DHCPv6 In-Reply-To: <9508311552.AA09490@xirtlu.zk3.dec.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Jim, Provided the server isn't bound by some small number of concurrent tcp streams and loss of state can be easily handled, I think this model will work. On the otherhand, there does appear to be a desire by some to allow for udp in all facets of the model. At the *risk of complicating* the protocol, would it be possible to allow either type of transport to be used? For example, two bits of the OFFER packet could be used by the server to advertise transport type availability to be used in the exchange of additional configuration information: 00 no tcp 01 tcp possible 10 prefer tcp 11 tcp only A server currently at its limit of tcp streams could advertise 00. Server administrators could be given the ability to configure the server to operate in a mode appropriate to their environment. A udp only client could shop around and NAK servers which had offered tcp only. johnc ------------------------------------------------------------------------------- John D. Carlson Networks and Distributed Computing EMAIL: johnc@cac.washington.edu University of Washington BELL: (206) 685-6204 4545 15th Ave NE FAX: (206) 685-4044 Seattle, WA 98105 On Thu, 31 Aug 1995 bound@zk3.dec.com wrote: > Date: Thu, 31 Aug 95 11:51:58 -0400 > From: bound@zk3.dec.com > To: host-conf@sol.eg.bucknell.edu > Cc: bound@zk3.dec.com > Subject: UDP/TCP in DHCPv6 > > Here is the model. I will not ask John Postel for TCP ports until the > next draft is out for a few weeks (we have UDP ports to get basic code > tested). I have tested this model with two implementors (not at my > place of work) and my own implementation effort in design and we think it > will work. > > Msg-Types (at this point) > > Client Server > > 1: client-discover (udp) > > 2: server-offer (udp) > > 3: client-ack (udp) [i accept your offer] > OR > 4: client-nak (udp) [i reject your offer] > > 6: server-offer-response (udp) > > 7: client-config-request (tcp) [additional config needed] > > 8: server-config-response (tcp) > > 9: client-revalidate-address (tcp) > > 8: server-config-response (tcp) > > The client-discover and server-offer responses must be limited to not be > greater than 576 octets. This design trade-off will make future > communications in DHCPv6 more efficient and elegant using the IPv6 > protocol model. > > I will add in the next draft an appendix discussing the rationale > discussions we have had for TCP use so readers know why we have moved in > this direction. > > Comments ???? > > thanks > /jim > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00968; 9 Sep 95 13:23 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ad00941; 9 Sep 95 13:23 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa23456; 8 Sep 95 23:09 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA25572; Fri, 8 Sep 1995 23:04:06 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA13102; Fri, 8 Sep 1995 22:59:06 -0400 Received: from coral.bucknell.edu by sol (5.x/SMI-SVR4) id AA00681; Fri, 8 Sep 1995 22:59:00 -0400 Received: from uvite53.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA25111; Fri, 8 Sep 1995 22:58:44 -0400 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Sep 1995 22:58:50 -0400 To: tomy@sfc.wide.ad.jp, host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Re: Question about 'ciaddr' usage in DISCOVER At 11:57 AM 8/19/95, Akihiro Tominaga wrote: >In the newest draft "draft-ietf-dhc-dhcp-02.txt", Page 36, Table 5, >there is description about 'ciaddr' like; > > Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE, > DHCPINFORM DHCPRELEASE > ----- ------------ ----------- ----------- > 'ciaddr' DHCPDISCOVER: 0 or client's client's network > 0 or client's network address address > netwrk address (BOUND/RENEW/REBIND) (DHCPRELEASE only) > (BOUND/RENEW/REBIND) > DHCPINFORM: client's > network address > >And my questions are; > >1. How can a client insert its network address in a DHCPDISCOVER ? > --> In my comprehension, a client never knows its own IP address when > it will send a DHCPDISCOVER. My mistake - when I wrote this I incorrectly remembered that a client sends a DHCPDISCOVER from REBINDING state. >2. What does "(BOUND/RENEW/REBIND)" mean ? > --> A client sends only DHCPREQUEST in "BOUND", "RENEW" and "REBIND" > state, doesn't it ? Same mistake. I've fixed it in the next draft. - Ralph   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01310; 9 Sep 95 13:23 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id bu00941; 9 Sep 95 13:23 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa04880; 9 Sep 95 11:25 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA10510; Sat, 9 Sep 1995 11:20:23 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA14962; Sat, 9 Sep 1995 11:16:39 -0400 Received: from savvy.ncm.com by sol (5.x/SMI-SVR4) id AA00942; Sat, 9 Sep 1995 11:16:32 -0400 Received: from telum.abies.com (guru@telum.abies.com [204.180.7.41]) by savvy.ncm.com (8.6.9/8.6.9) with SMTP id LAA22228 for ; Sat, 9 Sep 1995 11:11:36 -0400 Date: Sat, 9 Sep 1995 11:14:06 -29900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Simon Janes Subject: Bootp DHCP Configuration To: host-conf@sol.eg.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does anyone have an example bootptab and source to the "One True Bootpd+DHCP" that shows how to get bootpd+DHCP to tell a Windows for Workgroups machine using Microsoft's TCP/IP 3.11b to configure itself? Right now, my bootpd sees the Windows machine requesting for information, sends information back to it, but the Windows machine never configures itself, it just keeps requesting for information. -- Simon Janes   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02402; 9 Sep 95 16:03 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02398; 9 Sep 95 16:03 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa09466; 9 Sep 95 16:03 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA12046; Sat, 9 Sep 1995 15:55:59 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA17089; Sat, 9 Sep 1995 15:50:59 -0400 Received: from netmail2.microsoft.com by sol (5.x/SMI-SVR4) id AA01029; Sat, 9 Sep 1995 15:50:52 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA21788; Sat, 9 Sep 95 13:45:13 -0700 Received: by netmail2 using fxenixd 1.0 Sat, 09 Sep 95 13:45:13 PDT Message-Id: <9509091954.AA03905@itgmsm> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: jamesg@microsoft.com To: guru@ncm.com, host-conf@sol.eg.bucknell.edu Subject: RE: Bootp DHCP Configuration Date: Sat, 09 Sep 95 12:50:00 PDT X-Mailer: Microsoft Mail V3.0 Simon, The MS TCP/IP VxD stacks -- any version, any platform -- do NOT boot against a BOOTP server. They are all DHCP enabled and will boot using anyones DHCP server -- many of which they were tested against at various bakeoffs. Again, MS TCP/IP stacks -- WFW, Win95, NT or even for that matter our current DOS clients -- use DHCP but not BOOTP. jim ---------- |From: Simon Janes |To: host-conf |Subject: Bootp DHCP Configuration |Date: Saturday, September 09, 1995 11:14AM | | |Does anyone have an example bootptab and source to the "One True |Bootpd+DHCP" that shows how to get bootpd+DHCP to tell a Windows for |Workgroups machine using Microsoft's TCP/IP 3.11b to configure itself? | |Right now, my bootpd sees the Windows machine requesting for information, |sends information back to it, but the Windows machine never configures |itself, it just keeps requesting for information. | |-- |Simon Janes | |   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02664; 9 Sep 95 16:57 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02660; 9 Sep 95 16:57 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa10368; 9 Sep 95 16:57 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA20108; Sat, 9 Sep 1995 16:53:19 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA17482; Sat, 9 Sep 1995 16:46:51 -0400 Received: from savvy.ncm.com by sol (5.x/SMI-SVR4) id AA01047; Sat, 9 Sep 1995 16:46:44 -0400 Received: from telum.abies.com (guru@telum.abies.com [204.180.7.41]) by savvy.ncm.com (8.6.9/8.6.9) with SMTP id QAA23609; Sat, 9 Sep 1995 16:41:50 -0400 Date: Sat, 9 Sep 1995 16:44:10 -29900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Simon Janes Subject: RE: Bootp DHCP Configuration To: jamesg@microsoft.com Cc: host-conf@sol.eg.bucknell.edu In-Reply-To: <9509091954.AA03905@itgmsm> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 9 Sep 1995 jamesg@microsoft.com wrote: > The MS TCP/IP VxD stacks -- any version, any platform -- do NOT boot against > a BOOTP server. They are all DHCP enabled and will boot using anyones DHCP > server -- many of which they were tested against at various bakeoffs. > > Again, MS TCP/IP stacks -- WFW, Win95, NT or even for that matter our > current DOS clients -- use DHCP but not BOOTP. I'm using a bootp that claims to have DHCP patches, and the WFW stacks will not pay attention. Which Unix DHCP server(s) were they using at the bake-offs?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02942; 9 Sep 95 17:52 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02938; 9 Sep 95 17:52 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa11213; 9 Sep 95 17:53 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA27885; Sat, 9 Sep 1995 17:47:41 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA17755; Sat, 9 Sep 1995 17:43:53 -0400 Received: from netmail2.microsoft.com by sol (5.x/SMI-SVR4) id AA01071; Sat, 9 Sep 1995 17:43:46 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA22947; Sat, 9 Sep 95 15:38:09 -0700 Received: by netmail2 using fxenixd 1.0 Sat, 09 Sep 95 15:38:09 PDT Message-Id: <9509092146.AA09944@itgmsm> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: jamesg@microsoft.com To: guru@ncm.com Cc: host-conf@sol.eg.bucknell.edu Subject: RE: Bootp DHCP Configuration Date: Sat, 09 Sep 95 14:42:00 PDT X-Mailer: Microsoft Mail V3.0 Simon, I tested the WFW MS VxD stack DHCP against SUN, Competitive Automation, WIDE, FTP and Silicon Graphics servers way back at the pre-IETF bakeoff in toronto in july 1994. Except for issues involving servers which would not broadcast back -- since corrected by having our implementations accept direct sends to the MAC address -- we interoperated fine with everyone. Madan -- our DHCP developer at the time -- did some more interop testing back at a backoff in June (?). Unless anyone on the alias has some insight, I think we can take this off-alias for the next step our two, which would seem to be: A) if possible test a few other DHCP only clients to make sure, this thing actually boots a DHCP client B) send me some sniffs -- rhino.microsoft.com, dropoff subdir -- please send me some mail when you've slapped them up there. thanks, jim ---------- |From: Simon Janes |To: jamesg |Cc: host-conf |Subject: RE: Bootp DHCP Configuration |Date: Saturday, September 09, 1995 4:44PM | |On Sat, 9 Sep 1995 jamesg@microsoft.com wrote: | |> The MS TCP/IP VxD stacks -- any version, any platform -- do NOT boot |against |> a BOOTP server. They are all DHCP enabled and will boot using anyones |DHCP |> server -- many of which they were tested against at various bakeoffs. |> |> Again, MS TCP/IP stacks -- WFW, Win95, NT or even for that matter our |> current DOS clients -- use DHCP but not BOOTP. | |I'm using a bootp that claims to have DHCP patches, and the WFW stacks |will not pay attention. Which Unix DHCP server(s) were they using at the |bake-offs? | | |   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09019; 10 Sep 95 15:12 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09015; 10 Sep 95 15:12 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa01976; 10 Sep 95 15:12 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA04450; Sun, 10 Sep 1995 15:06:31 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA20818; Sun, 10 Sep 1995 15:01:25 -0400 Received: from decvax.dec.com (decvax.zk3.dec.com) by sol (5.x/SMI-SVR4) id AA01516; Sun, 10 Sep 1995 15:01:17 -0400 Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA13156; Sun, 10 Sep 1995 15:01:09 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA24495; Sun, 10 Sep 1995 15:01:07 -0400 Message-Id: <9509101901.AA24495@wasted.zk3.dec.com> To: host-conf@sol.eg.bucknell.edu Cc: bound@zk3.dec.com Subject: DHCPv6 New List and Importance Date: Sun, 10 Sep 95 15:01:07 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bound@zk3.dec.com X-Mts: smtp DHC WG, Ralph Droms has created a new list for DHCPv6 (dhcp-v6@bucknell.edu). I really hope folks on DHCPv4 will join that list as we enhance DHCPv6. A new draft will be forth coming in the next few weeks. I want to spend the time getting all the input I have received into that draft so we can have a solid foundation to discuss at the Dallas IETF meeting. The objective is to move to Proposed Standard after the Dallas IETF meeting. We will have at least two implementations prototyped for proof of concept too (though not normally required). Hopefully three. IPv6 I believe must begin to be deployed by 1998. Initial deployment IMHO cannot depend on the IPv6 routing structure to be in place at that time. Initial deployment will require DHCPv6 as networks integrate IPv6 into the initial IPv4 network toplogy, and absorb the new paradigms born out of the IETF work on IPv6 (e.g. DNSIND, Addr Conf, Neighbor Discovery). In addition its critical that we determine the "functions" in DHCPv6 we must carry forward from DHCPv4. For example it appears that Service Location can replace the need to locate services with DHCP. Is that OK? These and other questions must be discussed as part of DHCPv6. We are also free to develop new models that do not have to be backwards compatible with DHCPv4 (or bootp). We have a base spec now and we need a solid one by the time we walk away from the Dallas IETF meeting. Your involvment and expertise is needed. To join: send mail to listserve@bucknell.edu in the text somewhere enter: subscribe dhcp-v6 your-email-addr thanks for your support, /jim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09223; 10 Sep 95 15:47 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09219; 10 Sep 95 15:47 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa02560; 10 Sep 95 15:47 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA10245; Sun, 10 Sep 1995 15:42:56 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA20950; Sun, 10 Sep 1995 15:37:47 -0400 Received: from coral.bucknell.edu by sol (5.x/SMI-SVR4) id AA01527; Sun, 10 Sep 1995 15:37:41 -0400 Received: from uvite54.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA09369; Sun, 10 Sep 1995 15:37:31 -0400 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 10 Sep 1995 15:37:39 -0400 To: host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Re: DHCPv6 New List and Importance Two small followups to Jim's note about the DHCP-V6 mailing list: The address for admin requests is listserv@bucknell.edu. To subscribe, send a message with body: SUBSCRIBE DHCP-V6 John Doe where you should replace "John Doe" with your real name (the listserv processor will extract your e-mail address from your incoming mail message). If you subscribe with your real name, it's easier to track who is subscribed to the list... - Ralph   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06902; 11 Sep 95 7:30 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06898; 11 Sep 95 7:30 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa17916; 11 Sep 95 7:30 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA15855; Mon, 11 Sep 1995 07:24:50 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA24124; Mon, 11 Sep 1995 07:24:10 -0400 Received: from gate.ti.com (news.ti.com) by sol (5.x/SMI-SVR4) id AA01863; Mon, 11 Sep 1995 07:24:04 -0400 Received: from ganesh.mc.ti.com ([157.87.4.175]) by gate.ti.com (8.6.12/) with SMTP id GAA21457; Mon, 11 Sep 1995 06:24:01 -0500 Received: by ganesh.mc.ti.com; id AA25716; Mon, 11 Sep 1995 07:23:30 -0400 Message-Id: <9509111123.AA25716@ganesh.mc.ti.com> X-Sender: a722756@mail-ad.mc.ti.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Sep 1995 07:23:30 -0400 To: Simon Janes , host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "W. Donald Rolph III" Subject: Re: Bootp DHCP Configuration Using the WIDE software against wfw tcp/ip 32a 3.11a I am getting satisfactopry loading and configuration of wfw machines. Microsoft does not support bootp - it supports only DHCP, might this be the problem? At 11:14 AM 9/9/95 -29900, Simon Janes wrote: > >Does anyone have an example bootptab and source to the "One True >Bootpd+DHCP" that shows how to get bootpd+DHCP to tell a Windows for >Workgroups machine using Microsoft's TCP/IP 3.11b to configure itself? > >Right now, my bootpd sees the Windows machine requesting for information, >sends information back to it, but the Windows machine never configures >itself, it just keeps requesting for information. > >-- >Simon Janes > > > Regards. Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-236-1263   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06952; 11 Sep 95 7:38 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06948; 11 Sep 95 7:38 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa18052; 11 Sep 95 7:38 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA16675; Mon, 11 Sep 1995 07:34:50 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA24153; Mon, 11 Sep 1995 07:34:15 -0400 Received: from telum.abies.com by sol (5.x/SMI-SVR4) id AA01866; Mon, 11 Sep 1995 07:34:09 -0400 Received: from telum.abies.com (guru@telum.abies.com [204.180.7.41]) by telum.abies.com (8.6.9/8.6.9) with SMTP id HAA02298; Mon, 11 Sep 1995 07:31:34 -0400 Date: Mon, 11 Sep 1995 07:31:33 -29900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Simon Janes X-Orig-Sender: Simon Janes Reply-To: Simon Janes Subject: Re: Bootp DHCP Configuration To: "W. Donald Rolph III" Cc: host-conf@sol.eg.bucknell.edu In-Reply-To: <9509111123.AA25716@ganesh.mc.ti.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Ok. I have discovered my problem after looking at a lot of logs and binaries. 'make install' wasn't actually installing my bootpd+DHCP. Grrrrrr Someone else also said that they wanted to see a working bootptab for this situation, so I'll post a short one: .default:\ :hn:dn=abies.com:\ :ds=ns.abies.com, savvy.ncm.com:\ :sm=255.255.255.240:\ :gw=telum.abies.com:\ :dl=0x1209600:\ :vm=1048: hasta:tc=.default:ha=0x008029E4C0C1:ip=204.180.7.43: The bootpd that I finally got to work was bootpd-DD2.4.3, which has some dynamic allocation patches for DHCP clients. (Assigns addresses permanently as machines request addresses.) Thank you everyone for helping out! --- Simon Janes   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08142; 11 Sep 95 9:20 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08136; 11 Sep 95 9:20 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa20126; 11 Sep 95 9:19 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA28304; Mon, 11 Sep 1995 09:15:44 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA24781; Mon, 11 Sep 1995 09:14:34 -0400 Received: from mercury.Sun.COM by sol (5.x/SMI-SVR4) id AA01943; Mon, 11 Sep 1995 09:14:28 -0400 Received: from East.Sun.COM by mercury.Sun.COM (Sun.COM) id GAA17313; Mon, 11 Sep 1995 06:14:18 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (5.x/SMI-5.3) id AA20803; Mon, 11 Sep 1995 09:14:15 -0400 Received: from poori.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA10226; Mon, 11 Sep 1995 09:14:15 -0400 Received: from canoepoint by poori.East.Sun.COM (5.x/SMI-SVR4) id AA27220; Mon, 11 Sep 1995 09:14:11 -0400 Date: Mon, 11 Sep 1995 09:14:11 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Carney - Sun BOS Software Message-Id: <9509111314.AA27220@poori.East.Sun.COM> To: guru@ncm.com, jamesg@microsoft.com Subject: Re: RE: Bootp DHCP Configuration Cc: host-conf@sol.eg.bucknell.edu X-Mailer: Pronto E-Mail [version 2.0] Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'd be suspicious of the protocol compliance of the souped up bootpd you describe. I've never seen it tested at a DHCP interoperability test. However, we've always interoperated with Microsoft's client and server, from the first bakeoff. Mike Carney SunSoft Networking Chelmsford, MA   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08639; 11 Sep 95 9:44 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08635; 11 Sep 95 9:44 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa20617; 11 Sep 95 9:44 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA03059; Mon, 11 Sep 1995 09:40:11 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA25145; Mon, 11 Sep 1995 09:39:57 -0400 Received: from bastion.fdic.gov by sol (5.x/SMI-SVR4) id AA01951; Mon, 11 Sep 1995 09:39:52 -0400 Received: by bastion.fdic.gov; id AA23085; Mon, 11 Sep 95 09:41:29 EDT Received: from mailhub.fdic.gov(151.174.3.26) by bastion.fdic.gov via smap (V1.4) id sma023056; Mon Sep 11 09:41:19 1995 Received: by DACS_DC_16.FDIC.GOV; Mon, 11 Sep 95 9:39:29 -0400 Date: Mon, 11 Sep 95 9:38:13 -0400 Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Stacey Sykes To: host-conf@sol.eg.bucknell.edu Subject: ...no subject... please unsubsribe Stacey Sykes [ssykes@fdic.gov]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08890; 11 Sep 95 9:51 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08886; 11 Sep 95 9:51 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa20809; 11 Sep 95 9:51 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA03811; Mon, 11 Sep 1995 09:44:57 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA25202; Mon, 11 Sep 1995 09:44:28 -0400 Received: from bastion.fdic.gov by sol (5.x/SMI-SVR4) id AA01958; Mon, 11 Sep 1995 09:44:24 -0400 Received: by bastion.fdic.gov; id AA23430; Mon, 11 Sep 95 09:46:07 EDT Received: from mailhub.fdic.gov(151.174.3.26) by bastion.fdic.gov via smap (V1.4) id sma023400; Mon Sep 11 09:46:00 1995 Received: by DACS_DC_16.FDIC.GOV; Mon, 11 Sep 95 9:44:04 -0400 Date: Mon, 11 Sep 95 9:43:10 -0400 Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Stacey Sykes To: host-conf@sol.eg.bucknell.edu Subject: ...no subject... please unsubscribe Stacey Sykes [ssykes@fdic.gov]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07320; 16 Sep 95 7:12 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07316; 16 Sep 95 7:12 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa24014; 16 Sep 95 7:11 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA09485; Sat, 16 Sep 1995 07:06:50 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA28160; Sat, 16 Sep 1995 07:05:46 -0400 Received: from s.wipinfo.soft.net by sol (5.x/SMI-SVR4) id AA03993; Sat, 16 Sep 1995 07:05:13 -0400 Received: by s.wipinfo.soft.net (4.1/SMI-4.1) id AA08260; Sat, 16 Sep 95 16:37:58 IST Received: from comm10. by rolex.rnd.blr (4.1/SMI-4.1) id AA18072; Sat, 16 Sep 95 16:37:44+050 Received: from clab2. by comm10. (4.1/SMI-4.0) id AA08885; Sat, 16 Sep 95 16:48:05 IST Received: by clab2. (4.1/SMI-4.0) id AA14156; Sat, 16 Sep 95 16:48:08 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rajesh Saluja Message-Id: <9509161118.AA14156@clab2.> Subject: dhcp client impl. questions To: host-conf@sol.eg.bucknell.edu Date: Sat, 16 Sep 1995 16:48:08 +0530 (IST) Cc: Rajesh Saluja X-Mailer: ELM [version 2.4 PL23] Content-Type: text Hello , I am trying to implement DHCP client. For this, I am following the latest DHCP draft i.e. draft-ietf-dhc-dhcp-02.txt. I have some questions about the implementation: 1. What should be the value of 'secs' field in each BOOTREQUEST ? Should it be increased with each BOOTREQUEST? How does the treatment of this field varies with different REQUESTS( DISCOVER,REQUEST,RENEW,REBIND ) ? 2. In RENEWING/REBINDING, ciaddr is filled and message is unicasted. Should the client explicitly make the 'flags' 0? My confusion is that if the client sets the BROADCAST bit in the 'flags' while sending DHCPDECLINE, will the server broadcast the BOOTREPLY? or irrespective of the 'flags', it will unicast the REPLY to the requesting client? Will you please clarify my doubts? With thanks in anticipation: RAJESH SALUJA WIPRO INFOTECH LTD. BANGALORE ( INDIA )   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05084; 19 Sep 95 0:13 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05080; 19 Sep 95 0:13 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa02237; 19 Sep 95 0:13 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA22132; Tue, 19 Sep 1995 00:05:00 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA21531; Tue, 19 Sep 1995 00:04:24 -0400 Received: from coral.bucknell.edu by sol (5.x/SMI-SVR4) id AA05935; Tue, 19 Sep 1995 00:04:19 -0400 Received: from uvite54.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA21985; Tue, 19 Sep 1995 00:04:14 -0400 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Sep 1995 00:04:22 -0400 To: host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Revisions DHCP spec and options doc I've submitted revised versions of the DHCP spec and options docs publication as I-Ds. The revised versions are available for anonymous FTP in directory ftp.bucknell.edu:pub/dhcp. - Ralph Droms   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05116; 19 Sep 95 0:16 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05112; 19 Sep 95 0:16 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa02287; 19 Sep 95 0:16 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA22131; Tue, 19 Sep 1995 00:04:59 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA21530; Tue, 19 Sep 1995 00:04:21 -0400 Received: from coral.bucknell.edu by sol (5.x/SMI-SVR4) id AA05934; Tue, 19 Sep 1995 00:04:16 -0400 Received: from uvite54.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA21951; Tue, 19 Sep 1995 00:04:06 -0400 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Sep 1995 00:04:16 -0400 To: dhcp-v6@bucknell.edu, host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Re: DHCPv6 State and Plan At 7:00 PM 9/18/95, bound@zk3.dec.com wrote: >December 95: > > We need at least two 2 hour meetings for DHCPv6 at the Dallas IETF > to pound out the last changes we need to submit both the options and > the core spec. > > ** Ralph ** is this possible? If you think we can do this in one 2 > hour meeting let us know? But we need a complete meeting for DHCPv6 > with no other issues for the WG to deal with at Dallas. It would be > good if it did not run into other IPv6 meetings like addr conf, > neighbor discovery, or IPv6 base spec. As I think many of those folks > will be at DHCPv6 too. Two meetings in Dallas sounds doable. I don't think there will be a need for more than one DHCPv4 meeting. (Note that I've posted this specific message to the DHCPv4 list, too). I will do my bet to avoid other IPv6 meetings (but it won't be easy to miss them all!). - Ralph   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07436; 20 Sep 95 6:40 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07432; 20 Sep 95 6:40 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa06334; 20 Sep 95 6:40 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA01197; Wed, 20 Sep 1995 06:25:27 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA29251; Wed, 20 Sep 1995 06:23:04 -0400 Received: from s.wipinfo.soft.net by sol (5.x/SMI-SVR4) id AA07395; Wed, 20 Sep 1995 06:22:56 -0400 Received: by s.wipinfo.soft.net (4.1/SMI-4.1) id AA28614; Wed, 20 Sep 95 15:54:50 IST Received: from comm10. by rolex.rnd.blr (4.1/SMI-4.1) id AA29744; Wed, 20 Sep 95 15:55:20+050 Received: from clab2. by comm10. (4.1/SMI-4.0) id AA04027; Wed, 20 Sep 95 16:05:43 IST Received: by clab2. (4.1/SMI-4.0) id AA07829; Wed, 20 Sep 95 16:05:43 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rajesh Saluja Message-Id: <9509201035.AA07829@clab2.> Subject: DHCPRELEASE problem To: DHCP mailing list Date: Wed, 20 Sep 1995 16:05:42 +0530 (IST) Cc: Rajesh Saluja X-Mailer: ELM [version 2.4 PL23] Content-Type: text Hello, I see a problem with infinite lease in DHCP. Suppose the DHCP client has acquired an address from DHCP server for infinite lease. Now at some point of time, the client wants to release this address. It sends the DHCPRELEASE message to the server. Since there is no response to DHCPRELEASE from the server, the client can never be sure whether that address has been released or not. If DHCPRELEASE message could not reach the server because of any reason, that address will be blocked there. In this situation, neither the client nor the server can do anything. Any thought on this issue is most welcome. BEST REGARDS RAJESH SALUJA WIPRO INFOTECH LTD BANGALORE INDIA   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08809; 20 Sep 95 9:05 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08805; 20 Sep 95 9:05 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa08699; 20 Sep 95 9:05 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA15289; Wed, 20 Sep 1995 08:55:20 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA29583; Wed, 20 Sep 1995 08:54:45 -0400 Received: from ftp.com by sol (5.x/SMI-SVR4) id AA07467; Wed, 20 Sep 1995 08:54:40 -0400 Received: from ftp.com by ftp.com ; Wed, 20 Sep 1995 08:54:34 -0400 Received: from mailserv-C.ftp.com by ftp.com ; Wed, 20 Sep 1995 08:54:34 -0400 Received: from mamros.cavedog.ftp.com by mailserv-C.ftp.com (5.0/SMI-SVR4) id AA08916; Wed, 20 Sep 95 08:53:01 EDT Date: Wed, 20 Sep 95 08:53:01 EDT Message-Id: <9509201253.AA08916@mailserv-C.ftp.com> To: rsaluja@wipinfo.soft.net Subject: Re: DHCPRELEASE problem Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Shawn Mamros Cc: host-conf@sol.eg.bucknell.edu X-Orig-Sender: mamros@mailserv-c.ftp.com Repository: mailserv-C.ftp.com, [message accepted at Wed Sep 20 08:52:55 1995] Originating-Client: cavedog.ftp.com > I see a problem with infinite lease in DHCP. Suppose the DHCP > client has acquired an address from DHCP server for infinite lease. > Now at some point of time, the client wants to release this address. > It sends the DHCPRELEASE message to the server. Since there is no > response to DHCPRELEASE from the server, the client can never be sure > whether that address has been released or not. > If DHCPRELEASE message could not reach the server because of > any reason, that address will be blocked there. In this situation, > neither the client nor the server can do anything. Right, but why is this a problem? From the server's perspective, if one assigns an infinite lease time to a client, that client may choose to hold on to that address forever. After all, that's exactly what "infinite" means. The server has no way of knowing whether or not that client will actually release that address sometime later, and the server is not allowed to time out the lease. IMO, if one chooses to use infinite lease times, then they'd better understand the full ramifications of what that means, and especially if they use an infinite lease time for dynamic leases. If you want to guarantee that addresses will be freed up, put a finite time on the lease - you can make them as long as you like (the protocol allows for lease times >100 years!). That doesn't mean that infinite leases aren't useful. Certainly, for static address assignments, they may make lots of sense in some environments (effectively, DHCP becomes little more than BOOTP in that case). Even for dynamic assignments, I could see a sysadmin decide to use DHCP just for bootstrapping a bunch of machines, where she wants those machines to have permanent addresses but doesn't want to have to pick which address goes to which machine - let DHCP perform that task. -Shawn Mamros E-mail to: mamros@ftp.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11439; 20 Sep 95 11:24 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11435; 20 Sep 95 11:24 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa12455; 20 Sep 95 11:24 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA15867; Wed, 20 Sep 1995 11:09:20 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA01117; Wed, 20 Sep 1995 11:08:36 -0400 Received: from VNET.IBM.COM by sol (5.x/SMI-SVR4) id AA07951; Wed, 20 Sep 1995 11:08:29 -0400 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5177; Wed, 20 Sep 95 11:07:58 EDT Received: by RTP (XAGENTA 4.0) id 3391; Wed, 20 Sep 1995 11:07:33 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18322; Wed, 20 Sep 1995 11:07:45 -0400 Message-Id: <9509201507.AA18322@cichlid.raleigh.ibm.com> To: Shawn Mamros Cc: rsaluja@wipinfo.soft.net, host-conf@sol.eg.bucknell.edu Subject: Re: DHCPRELEASE problem In-Reply-To: Your message of "Wed, 20 Sep 1995 08:53:01 EDT." <9509201253.AA08916@mailserv-C.ftp.com> Date: Wed, 20 Sep 1995 11:07:33 +22305558 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Narten >> I see a problem with infinite lease in DHCP. Suppose the DHCP >> client has acquired an address from DHCP server for infinite lease. >> Now at some point of time, the client wants to release this address. >> It sends the DHCPRELEASE message to the server. Since there is no >> response to DHCPRELEASE from the server, the client can never be sure >> whether that address has been released or not. >> If DHCPRELEASE message could not reach the server because of >> any reason, that address will be blocked there. In this situation, >> neither the client nor the server can do anything. >Right, but why is this a problem? It's terribly inefficient. The client must continue to send DHCPRELEASE messages for a (potentially) infinite time if it wants to be sure the server knows the address has been freed up. The client has no way of knowing how many tries are enough. A simply ACK from the server would allow the client to move on to other things. A server ACK would be a straightforward and simple message to add. What is the rational for not having one? >to time out the lease. IMO, if one chooses to use infinite lease times, >then they'd better understand the full ramifications of what that means, >and especially if they use an infinite lease time for dynamic leases. >If you want to guarantee that addresses will be freed up, put a finite >time on the lease - you can make them as long as you like (the protocol >allows for lease times >100 years!). The problem with the above is that if you ever screw up once, you pay the price forever, since there is no easy way to "undo" the damage. Thomas   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12864; 20 Sep 95 13:22 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12860; 20 Sep 95 13:22 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa14845; 20 Sep 95 13:22 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA28492; Wed, 20 Sep 1995 12:04:16 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA01530; Wed, 20 Sep 1995 12:01:52 -0400 Received: from s.wipinfo.soft.net by sol (5.x/SMI-SVR4) id AA08232; Wed, 20 Sep 1995 12:01:41 -0400 Received: by s.wipinfo.soft.net (4.1/SMI-4.1) id AA02520; Wed, 20 Sep 95 21:33:46 IST Received: from comm10. by rolex.rnd.blr (4.1/SMI-4.1) id AA10379; Wed, 20 Sep 95 21:34:15+050 Received: from clab2. by comm10. (4.1/SMI-4.0) id AA00863; Wed, 20 Sep 95 21:44:38 IST Received: by clab2. (4.1/SMI-4.0) id AA00704; Wed, 20 Sep 95 21:44:38 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rajesh Saluja Message-Id: <9509201614.AA00704@clab2.> Subject: Re: DHCPRELEASE problem To: Shawn Mamros Date: Wed, 20 Sep 1995 21:44:37 +0530 (IST) Cc: DHCP MAILING LIST , Rajesh Saluja In-Reply-To: <9509201253.AA08916@mailserv-C.ftp.com> from "Shawn Mamros" at Sep 20, 95 08:53:01 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text > > > I see a problem with infinite lease in DHCP. Suppose the DHCP > > client has acquired an address from DHCP server for infinite lease. > > Now at some point of time, the client wants to release this address. > > It sends the DHCPRELEASE message to the server. Since there is no > > response to DHCPRELEASE from the server, the client can never be sure > > whether that address has been released or not. > > If DHCPRELEASE message could not reach the server because of > > any reason, that address will be blocked there. In this situation, > > neither the client nor the server can do anything. > > Right, but why is this a problem? From the server's perspective, if one > assigns an infinite lease time to a client, that client may choose to > hold on to that address forever. After all, that's exactly what "infinite" > means. The server has no way of knowing whether or not that client will > actually release that address sometime later, and the server is not allowed > to time out the lease. IMO, if one chooses to use infinite lease times, > then they'd better understand the full ramifications of what that means, > and especially if they use an infinite lease time for dynamic leases. > If you want to guarantee that addresses will be freed up, put a finite > time on the lease - you can make them as long as you like (the protocol > allows for lease times >100 years!). > > That doesn't mean that infinite leases aren't useful. Certainly, for > static address assignments, they may make lots of sense in some environments > (effectively, DHCP becomes little more than BOOTP in that case). Even > for dynamic assignments, I could see a sysadmin decide to use DHCP just > for bootstrapping a bunch of machines, where she wants those machines > to have permanent addresses but doesn't want to have to pick which address > goes to which machine - let DHCP perform that task. > Thanks for your reply. I would like to tell how this problem arises. Suppose that the DHCP is being used by a remote access product for giving the address to the remote end of PPP connection. Once the address hasbeen acquired by the client, that address is given to some remote machine. In this way, a client can get so many addresses for different remote machines using different client identifiers. ( I think that Shiva does that ). In this situation, REBIND/RENEW is very difficult. Because the response to a REBIND/RENEW is an unicast, it is difficult for such a client to handle the responses to RENEW/REBIND for addresses of remote machines. Moreover, it is also likely that such a response will never come to the client ( i.e. the remote access product where the dhcp client is running) because if the server is not on the local net then it may find a shorter route to send that message to the remote machine ( i.e. the machine which got the address from remote access product through DHCP). ( I hope that it makes sense...). So the best solution is that even if I do not need the address permanently, get it for infinite lease sothat I should not bother about RENEWING.( Is it convincing ?? ) and whenever the address is not required, release it by DHCPRELEASE. And here comes the problem, that I had mentioned. What if server is down? If the client can get any ACK/NAK for RELEASE, it can take the appropriate action ( e.g. if it could not release, release after some time ). But since there is no response to DHCPRELEASE, the address will get blocked and it will never be released. Regards RAJESH SALUJA   Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13553; 20 Sep 95 13:53 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15484; 20 Sep 95 13:53 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13501; 20 Sep 95 13:53 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13265; 20 Sep 95 13:46 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: host-conf@sol.eg.bucknell.edu Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-dhc-dhcp-03.txt Date: Wed, 20 Sep 95 13:46:01 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9509201346.aa13265@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Dynamic Host Configuration Protocol Author(s) : R. Droms Filename : draft-ietf-dhc-dhcp-03.txt Pages : 44 Date : 09/19/1995 The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior of BOOTP relay agents [7, 21], and DHCP participants can interoperate with BOOTP participants [9]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcp-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcp-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcp-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950919135229.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcp-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950919135229.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13590; 20 Sep 95 13:54 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13555; 20 Sep 95 13:53 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15483; 20 Sep 95 13:53 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13500; 20 Sep 95 13:53 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13312; 20 Sep 95 13:47 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: host-conf@sol.eg.bucknell.edu X-Orig-Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-dhc-options-1533update-01.txt Date: Wed, 20 Sep 95 13:47:09 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9509201347.aa13312@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Options and BOOTP Vendor Extensions Author(s) : S. Alexander, R. Droms Filename : draft-ietf-dhc-options-1533update-01.txt Pages : 36 Date : 09/19/1995 The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called "options." This document specifies the current set of DHCP options. This document will be periodically updated as new options are defined. Each superseding document will include the entire current list of valid options. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments [22]. All of the vendor information extensions defined in RFC 1497 [2] may be used as DHCP options. The definitions given in RFC 1497 are included in this document, which supersedes RFC 1497. All of the DHCP options defined in this document, except for those specific to DHCP as defined in section 9, may be used as BOOTP vendor information extensions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-options-1533update-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-options-1533update-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-options-1533update-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950919092311.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-options-1533update-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-options-1533update-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950919092311.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16018; 20 Sep 95 16:22 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16014; 20 Sep 95 16:22 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa19256; 20 Sep 95 16:22 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA01786; Wed, 20 Sep 1995 16:09:21 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA03713; Wed, 20 Sep 1995 16:07:58 -0400 Received: from shiva-dev.shiva.com (shiva.com) by sol (5.x/SMI-SVR4) id AA08539; Wed, 20 Sep 1995 16:07:52 -0400 Received: (jhw@localhost) by shiva-dev.shiva.com (8.6.9/8.6.4) id QAA06514 for host-conf@sol.eg.bucknell.edu; Wed, 20 Sep 1995 16:07:50 -0400 Date: Wed, 20 Sep 1995 16:07:50 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jonathan Wenocur Message-Id: <199509202007.QAA06514@shiva-dev.shiva.com> To: host-conf@sol.eg.bucknell.edu Subject: Re: DHCPRELEASE problem >> From: rsaluja@wipinfo.soft.net (Rajesh Saluja) >> Message-Id: <9509201614.AA00704@clab2.> >> >> [...] >> >> Thanks for your reply. I would like to tell how this problem >> arises. Suppose that the DHCP is being used by a remote access >> product for giving the address to the remote end of PPP >> connection. Once the address hasbeen acquired by the client, that >> address is given to some remote machine. In this way, a client >> can get so many addresses for different remote machines using >> different client identifiers. ( I think that Shiva does that ). >> In this situation, REBIND/RENEW is very difficult. Because >> the response to a REBIND/RENEW is an unicast, it is difficult for >> such a client to handle the responses to RENEW/REBIND for >> addresses of remote machines. Moreover, it is also likely that >> such a response will never come to the client ( i.e. the remote >> access product where the dhcp client is running) because if the >> server is not on the local net then it may find a shorter route >> to send that message to the remote machine ( i.e. the machine >> which got the address from remote access product through DHCP). >> ( I hope that it makes sense...). How could this happen for a dial-in client? How is there an alternate route to a dial-in client, shouldn't the only route be through the remote access server it's dialed into? >> So the best solution is that even if I do not need the address >> permanently, get it for infinite lease sothat I should not bother >> about RENEWING.( Is it convincing ?? ) and whenever the address is not >> required, release it by DHCPRELEASE. >> And here comes the problem, that I had mentioned. What if server >> is down? If the client can get any ACK/NAK for RELEASE, it can take >> the appropriate action ( e.g. if it could not release, release after some >> time ). But since there is no response to DHCPRELEASE, the address will >> get blocked and it will never be released. What if the dial-in connection goes down unexpectedly, you wouldn't get a chance to do a RELEASE anyway. I think where Shawn was leading is that the use of infinite leases is generally (highly) discouraged -- kind of defeats the purpose of dynamic address assignment. Very long leases are okay. (Just as a reference point we don't allow leases longer than 48 hours for dial-in clients. And the remote access server handles all of the renewal stuff.) -- Jonathan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16269; 20 Sep 95 16:36 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16265; 20 Sep 95 16:36 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa19509; 20 Sep 95 16:36 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA04575; Wed, 20 Sep 1995 16:21:33 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA03788; Wed, 20 Sep 1995 16:20:19 -0400 Received: from gate.isotro.ca by sol (5.x/SMI-SVR4) id AA08551; Wed, 20 Sep 1995 16:20:11 -0400 Received: from localhost (uucp@localhost) by gate.isotro.ca (8.6.5/8.6.6) id QAA16966 for ; Wed, 20 Sep 1995 16:17:21 -0400 Received: from vertige.isotro.ca(198.235.176.15) by gate.isotro.ca via smap (V1.3) id sma016964; Wed Sep 20 16:16:57 1995 Received: from closer.isotro.ca (closure.isotro.ca) by vertige.isotro.ca (4.1/SMI-4.1) id AA02015; Wed, 20 Sep 95 16:19:19 EDT Message-Id: <9509202019.AA02015@vertige.isotro.ca> X-Sender: gregg@vertige.isotro.ca Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Sep 1995 16:14:54 -0500 To: host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gregg Duncan Subject: subscribe X-Mailer: subcribe =============================================================== ISOTRO Network Management Inc Phone: (613) 722 1921 Ext.#30 875 Carling Ave Toll Free: 1-800-476-8762 Ottawa, Ontario, Canada, Fax: (613) 722 1997 K1S 5P1 Email: gregg@isotro.ca WWW: www.isotro.ca   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17593; 20 Sep 95 17:39 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17589; 20 Sep 95 17:39 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa20941; 20 Sep 95 17:39 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA20750; Wed, 20 Sep 1995 17:14:57 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA04015; Wed, 20 Sep 1995 17:13:46 -0400 Received: from ftp.com by sol (5.x/SMI-SVR4) id AA08600; Wed, 20 Sep 1995 17:13:40 -0400 Received: from ftp.com by ftp.com ; Wed, 20 Sep 1995 17:13:37 -0400 Received: from mailserv-C.ftp.com by ftp.com ; Wed, 20 Sep 1995 17:13:37 -0400 Received: from mamros.cavedog.ftp.com by mailserv-C.ftp.com (5.0/SMI-SVR4) id AA17067; Wed, 20 Sep 95 17:12:03 EDT Date: Wed, 20 Sep 95 17:12:03 EDT Message-Id: <9509202112.AA17067@mailserv-C.ftp.com> To: rsaluja@wipinfo.soft.net Subject: Re: DHCPRELEASE problem Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Shawn Mamros Reply-To: mamros@ftp.com Cc: host-conf@sol.eg.bucknell.edu X-Orig-Sender: mamros@mailserv-c.ftp.com Repository: mailserv-C.ftp.com, [message accepted at Wed Sep 20 17:11:38 1995] Originating-Client: cavedog.ftp.com > Suppose that the DHCP is being used by a remote access product for giving the address to the remote end of PPP connection. Once the address hasbeen acquired > by the client, that address is given to some remote machine. In this > way, a client can get so many addresses for different remote machines > using different client identifiers. ( I think that Shiva does that ). OK, so we're talking about a sort of "proxy DHCP client", right? I'm familiar with the Shiva implementation... > In this situation, REBIND/RENEW is very difficult. Because the response > to a REBIND/RENEW is an unicast, it is difficult for such a client to > handle the responses to RENEW/REBIND for addresses of remote machines. > Moreover, it is also likely that such a response will never come to the > client ( i.e. the remote access product where the dhcp client is running) > because if the server is not on the local net then it may > find a shorter route to send that message to the remote machine ( i.e. > the machine which got the address from remote access product through DHCP). > ( I hope that it makes sense...). Unless I'm mistaken, Shiva's setup provides only one route to the remote machine via a serial line. It sounds like you're saying that your remote machine can potentially be multihomed? Even then, I'm not entirely certain how a separate route can be completely set up, unless your remote system is also set up as a router (and, as it says right near the beginning of the DHCP RFC, DHCP is not intended for use in configuring routers...). > So the best solution is that even if I do not need the address > permanently, get it for infinite lease sothat I should not bother > about RENEWING.( Is it convincing ?? ) and whenever the address is not > required, release it by DHCPRELEASE. What do you do about servers which are configured to give out only finite leases, in spite of you requesting an infinite one? Do you reject all non-infinite offers? > And here comes the problem, that I had mentioned. What if server > is down? If the client can get any ACK/NAK for RELEASE, it can take > the appropriate action ( e.g. if it could not release, release after some > time ). But since there is no response to DHCPRELEASE, the address will > get blocked and it will never be released. As I said in my response to Thomas, 1) good server implementations ought to allow some means of manually releasing such a lease if need be, and 2) perhaps this can be solved with some sort of separate message type for a release requesting an ACK, but I would be strongly opposed to changing the semantics of the existing DHCPRELEASE. -Shawn Mamros E-mail to: mamros@ftp.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17646; 20 Sep 95 17:42 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17641; 20 Sep 95 17:42 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa21002; 20 Sep 95 17:42 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA20605; Wed, 20 Sep 1995 17:14:41 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA04016; Wed, 20 Sep 1995 17:13:47 -0400 Received: from ftp.com by sol (5.x/SMI-SVR4) id AA08601; Wed, 20 Sep 1995 17:13:41 -0400 Received: from ftp.com by ftp.com ; Wed, 20 Sep 1995 17:13:25 -0400 Received: from mailserv-C.ftp.com by ftp.com ; Wed, 20 Sep 1995 17:13:25 -0400 Received: from mamros.cavedog.ftp.com by mailserv-C.ftp.com (5.0/SMI-SVR4) id AA17048; Wed, 20 Sep 95 17:11:43 EDT Date: Wed, 20 Sep 95 17:11:43 EDT Message-Id: <9509202111.AA17048@mailserv-C.ftp.com> To: narten@vnet.ibm.com Subject: Re: DHCPRELEASE problem Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Shawn Mamros Reply-To: mamros@ftp.com Cc: rsaluja@wipinfo.soft.net, host-conf@sol.eg.bucknell.edu X-Orig-Sender: mamros@mailserv-c.ftp.com Repository: mailserv-C.ftp.com, [message accepted at Wed Sep 20 17:11:35 1995] Originating-Client: cavedog.ftp.com (Scenario: a DHCPRELEASE message is issued by a client with an infinite lease, but the message is dropped somewhere between client and server...) >>Right, but why is this a problem? > >It's terribly inefficient. The client must continue to send >DHCPRELEASE messages for a (potentially) infinite time if it wants to >be sure the server knows the address has been freed up. The client >has no way of knowing how many tries are enough. A simply ACK from >the server would allow the client to move on to other things. > >A server ACK would be a straightforward and simple message to >add. What is the rational for not having one? While I wasn't part of the DHCP WG when this was defined, I can venture a guess as to why this is this way (or at least the reason why I support the currently-defined behavior): consider the case of a client issuing a DHCPRELEASE as part of system shutdown. From the client's perspective, you don't want to have to be waiting around for an ACK to come back, nor do you particularly care - management of addresses is the responsibility of the server, after all. In the case of a finite lease, this isn't a problem, as the lease will time out on its own without the need for a DHCPRELEASE. Every client implementation of which I am aware that supports DHCPRELEASE sends it out once and only once. >The problem with the above is that if you ever screw up once, you pay >the price forever, since there is no easy way to "undo" the damage. Only if the server doesn't provide you with a means of removing an entry, one way or another. Hopefully, good server implementations will allow some way of doing so (with warning messages as appropriate). I think there's an analogy that can be drawn here with TCP, which provides both FIN (which requires an ACK) and RST (which doesn't). DHCPRELEASE implements RST; you'd rather that it behave more like FIN. Well, just as there are reasons to have both RST and FIN in TCP, perhaps there's enough justification to have both DHCPRELEASE and an "ACKed DHCPRELEASE". I certainly would argue that it should be a separate message type, rather than changing the semantics of DHCPRELEASE at this late date; there are too many production DHCP servers out there already... -Shawn Mamros E-mail to: mamros@ftp.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18290; 20 Sep 95 18:08 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18286; 20 Sep 95 18:08 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa21622; 20 Sep 95 18:08 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA08555; Wed, 20 Sep 1995 17:56:54 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA04307; Wed, 20 Sep 1995 17:56:28 -0400 Received: from puli.cisco.com by sol (5.x/SMI-SVR4) id AA08639; Wed, 20 Sep 1995 17:56:22 -0400 Received: (irfan@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id OAA01863; Wed, 20 Sep 1995 14:56:01 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Syed M. Irfan Ashraf" Message-Id: <199509202156.OAA01863@puli.cisco.com> Subject: Re: DHCPRELEASE problem To: mamros@ftp.com Date: Wed, 20 Sep 95 14:56:01 PDT Cc: narten@vnet.ibm.com, rsaluja@wipinfo.soft.net, host-conf@sol.eg.bucknell.edu In-Reply-To: <9509202111.AA17048@mailserv-C.ftp.com>; from "Shawn Mamros" at Sep 20, 95 5:11 pm X-Mailer: ELM [version 2.3 PL11] > a DHCPRELEASE as part of system shutdown. From the client's perspective, > you don't want to have to be waiting around for an ACK to come back, nor > do you particularly care - management of addresses is the responsibility > of the server, after all. In the case of a finite lease, this isn't a > problem, as the lease will time out on its own without the need for a > DHCPRELEASE. Your perspective of a client is quire narrow. There are people out there using DHCP to allocate temporary address (for whatever purpose) and then relinquishing it with DHCPRELEASE, w/o any shutdown involved. Both Shiva and Ciscos use this to feed addresses to dial-in clients. Even for finite leases, it is nice to be able to ensure that the server did get the DHCPRELEASE. > Every client implementation of which I am aware that supports DHCPRELEASE > sends it out once and only once. Ciscos send more than once. This because, in a number of configurations the DHCP server is located multiple hops away, serving a number of network segments. We have seen the DHCPRELEASE getting dropped by routers, all the time. Specially some routers drop the packet and arp, instead of holding on to the packet and arping. Sending multiple DCHPRELEASE only makes the chances better, but still doesn't guarantee delivery. > I certainly would argue that it should be a separate message type, rather > than changing the semantics of DHCPRELEASE at this late date; there are > too many production DHCP servers out there already... Why do we have to change the semantic ? If the server is updated, it can send the Release-ack. If not the client will just retry & time-out. Nothing mandatory suggested here. Will be compatible with prior specifications. -Irfan > -Shawn Mamros > E-mail to: mamros@ftp.com > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20138; 20 Sep 95 20:53 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20134; 20 Sep 95 20:53 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa24101; 20 Sep 95 20:53 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA08335; Wed, 20 Sep 1995 20:44:06 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA04843; Wed, 20 Sep 1995 20:43:32 -0400 Received: from netmail2.microsoft.com by sol (5.x/SMI-SVR4) id AA08736; Wed, 20 Sep 1995 20:43:25 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA07819; Wed, 20 Sep 95 18:40:06 -0700 Received: by netmail2 using fxenixd 1.0 Wed, 20 Sep 95 18:40:05 PDT Message-Id: <9509202047.AA03858@itgmsm> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: jamesg@microsoft.com To: narten@vnet.ibm.com Cc: host-conf@sol.eg.bucknell.edu Subject: Re: DHCPRELEASE problem Date: Wed, 20 Sep 95 13:40:00 PDT X-Mailer: Microsoft Mail V3.0 I must toss my two cents in here. DHCP is not a peer-peer protocol. It's a server that has an address pool, loaning out addresses to clients. Having an ACK on a RELEASE, seems to me to turn the concept of client / server on its head. When a client issues a RELEASE, it's giving a polite "I'm done. Thanks for the memories. Later." The client might be being unplugged to head on a business trip, hanging up, or moving to another subnet, whatever. It's NOT the client's job to sit around and retry -- waiting for its server to come back on-line! It's the server's job to make sure the IP address pool is managed correctly. The server can NEVER GUARANTEE it will be around whenever a client decides to give up its lease. That's why DHCP gives the server a recovery mechanism -- a finite lease. If you choose to throw away this feature of DHCP, then obviously the admin will have many of the problems associated with static leases. Deal. Don't try to dirty up the protocol, making the client a "partner in address pool maintenance" trying to pretend that you can create a failsafe leasing protocol without a timeout -- it can not be done. jim ---------- |From: Thomas Narten |To: mamros |Cc: rsaluja; host-conf |Subject: Re: DHCPRELEASE problem |Date: Wednesday, September 20, 1995 11:07AM | |>> I see a problem with infinite lease in DHCP. Suppose the DHCP |>> client has acquired an address from DHCP server for infinite lease. |>> Now at some point of time, the client wants to release this address. |>> It sends the DHCPRELEASE message to the server. Since there is no |>> response to DHCPRELEASE from the server, the client can never be sure |>> whether that address has been released or not. |>> If DHCPRELEASE message could not reach the server because of |>> any reason, that address will be blocked there. In this situation, |>> neither the client nor the server can do anything. | |>Right, but why is this a problem? | |It's terribly inefficient. The client must continue to send |DHCPRELEASE messages for a (potentially) infinite time if it wants to |be sure the server knows the address has been freed up. The client |has no way of knowing how many tries are enough. A simply ACK from |the server would allow the client to move on to other things. | |A server ACK would be a straightforward and simple message to |add. What is the rational for not having one? | |>to time out the lease. IMO, if one chooses to use infinite lease times, |>then they'd better understand the full ramifications of what that means, |>and especially if they use an infinite lease time for dynamic leases. |>If you want to guarantee that addresses will be freed up, put a finite |>time on the lease - you can make them as long as you like (the protocol |>allows for lease times >100 years!). | |The problem with the above is that if you ever screw up once, you pay |the price forever, since there is no easy way to "undo" the damage. | |Thomas |   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20443; 20 Sep 95 21:25 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20439; 20 Sep 95 21:25 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa24549; 20 Sep 95 21:25 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA15906; Wed, 20 Sep 1995 21:16:31 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA05000; Wed, 20 Sep 1995 21:16:11 -0400 Received: from puli.cisco.com by sol (5.x/SMI-SVR4) id AA08755; Wed, 20 Sep 1995 21:16:05 -0400 Received: (irfan@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id SAA09621; Wed, 20 Sep 1995 18:03:49 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Syed M. Irfan Ashraf" Message-Id: <199509210103.SAA09621@puli.cisco.com> Subject: Re: DHCPRELEASE problem To: jamesg@microsoft.com Date: Wed, 20 Sep 95 18:03:48 PDT Cc: narten@vnet.ibm.com, host-conf@sol.eg.bucknell.edu In-Reply-To: <9509202047.AA03858@itgmsm>; from "jamesg@microsoft.com" at Sep 20, 95 1:40 pm X-Mailer: ELM [version 2.3 PL11] > I must toss my two cents in here. > > DHCP is not a peer-peer protocol. It's a server that has an address pool, > loaning out addresses to clients. > > Having an ACK on a RELEASE, seems to me to turn the concept of client / > server on its head. When a client issues a RELEASE, it's giving a polite > "I'm done. Thanks for the memories. Later." The client might be being > unplugged to head on a business trip, hanging up, or moving to another > subnet, whatever. It's NOT the client's job to sit around and retry -- > waiting for its server to come back on-line! It's the server's job to make > sure the IP address pool is managed correctly. > > The server can NEVER GUARANTEE it will be around whenever a client decides > to give up its lease. That's why DHCP gives the server a recovery > mechanism -- a finite lease. If you choose to throw away this feature of > DHCP, then obviously the admin will have many of the problems associated > with static leases. Deal. Don't try to dirty up the protocol, making the > client a "partner in address pool maintenance" trying to pretend that you > can create a failsafe leasing protocol without a timeout -- it can not be > done. The gist of the proposal was that the release-ack would be optional. For those clients (or proxy-clients) that care, this will help them clean-up early instead of sending multiple RELEASE to be sure. Nothing mandatory about getting an Ack, has been suggested. -Irfan > jim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06486; 21 Sep 95 2:15 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06482; 21 Sep 95 2:15 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa03474; 21 Sep 95 2:15 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA22444; Thu, 21 Sep 1995 02:06:49 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA05836; Thu, 21 Sep 1995 02:05:34 -0400 Received: from decvax.dec.com (decvax.zk3.dec.com) by sol (5.x/SMI-SVR4) id AA08914; Thu, 21 Sep 1995 02:05:27 -0400 Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA22706; Thu, 21 Sep 1995 02:05:14 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA08153; Thu, 21 Sep 1995 02:05:12 -0400 Message-Id: <9509210605.AA08153@wasted.zk3.dec.com> To: mamros@ftp.com Cc: narten@vnet.ibm.com, rsaluja@wipinfo.soft.net, host-conf@sol.eg.bucknell.edu Subject: Re: DHCPRELEASE problem In-Reply-To: Your message of "Wed, 20 Sep 95 17:11:43 EDT." <9509202111.AA17048@mailserv-C.ftp.com> Date: Thu, 21 Sep 95 02:05:12 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bound@zk3.dec.com X-Mts: smtp >I think there's an analogy that can be drawn here with TCP, which provides >both FIN (which requires an ACK) and RST (which doesn't). DHCPRELEASE >implements RST; you'd rather that it behave more like FIN. Well, just >as there are reasons to have both RST and FIN in TCP, perhaps there's >enough justification to have both DHCPRELEASE and an "ACKed DHCPRELEASE". >I certainly would argue that it should be a separate message type, rather >than changing the semantics of DHCPRELEASE at this late date; there are >too many production DHCP servers out there already... This makes sense to me and I agree with Shawn. We are also faced at the server that the ack may have not gotten back to the client, which TCP is not faced with at the send via the client. If the server does not respond the send fails (at least this is possible). But we really need to consider the effect to the many existing production servers in the market presently and expanding exponentially IMHO. /jim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08004; 21 Sep 95 5:11 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08000; 21 Sep 95 5:11 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa05802; 21 Sep 95 5:11 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA01727; Thu, 21 Sep 1995 05:02:25 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA06010; Thu, 21 Sep 1995 05:01:52 -0400 Received: from s.wipinfo.soft.net by sol (5.x/SMI-SVR4) id AA08972; Thu, 21 Sep 1995 05:01:43 -0400 Received: by s.wipinfo.soft.net (4.1/SMI-4.1) id AA15404; Thu, 21 Sep 95 14:33:55 IST Received: from comm10. by rolex.rnd.blr (4.1/SMI-4.1) id AA16428; Thu, 21 Sep 95 14:34:22+050 Received: from clab2. by comm10. (4.1/SMI-4.0) id AA03737; Thu, 21 Sep 95 14:44:46 IST Received: by clab2. (4.1/SMI-4.0) id AA06884; Thu, 21 Sep 95 14:44:46 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rajesh Saluja Message-Id: <9509210914.AA06884@clab2.> Subject: Re: DHCPRELEASE problem To: mamros@ftp.com Date: Thu, 21 Sep 1995 14:44:45 +0530 (IST) Cc: Rajesh Saluja , DHCP MAILING LIST In-Reply-To: <9509202112.AA17067@mailserv-C.ftp.com> from "Shawn Mamros" at Sep 20, 95 05:12:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text > > Suppose that the DHCP is being used by a remote access product for giving the address to the remote end of PPP connection. Once the address hasbeen acquired > > by the client, that address is given to some remote machine. In this > > way, a client can get so many addresses for different remote machines > > using different client identifiers. ( I think that Shiva does that ). > > OK, so we're talking about a sort of "proxy DHCP client", right? EXACTLY.. > > > In this situation, REBIND/RENEW is very difficult. Because the response > > to a REBIND/RENEW is an unicast, it is difficult for such a client to > > handle the responses to RENEW/REBIND for addresses of remote machines. > > Moreover, it is also likely that such a response will never come to the > > client ( i.e. the remote access product where the dhcp client is running) > > because if the server is not on the local net then it may > > find a shorter route to send that message to the remote machine ( i.e. > > the machine which got the address from remote access product through DHCP). > > ( I hope that it makes sense...). > > Unless I'm mistaken, Shiva's setup provides only one route to the remote > machine via a serial line. It sounds like you're saying that your remote > machine can potentially be multihomed? Even then, I'm not entirely certain > how a separate route can be completely set up, unless your remote system > is also set up as a router (and, as it says right near the beginning of > the DHCP RFC, DHCP is not intended for use in configuring routers...). That is right. I was considering the situation when my remote system is set up as a router. I see the point... that we should not configure router through DHCP. > As I said in my response to Thomas, 1) good server implementations ought > to allow some means of manually releasing such a lease if need be, and > 2) perhaps this can be solved with some sort of separate message type > for a release requesting an ACK, but I would be strongly opposed to > changing the semantics of the existing DHCPRELEASE. > I think that it can be a good idea to send an ACK for DHCPRELEASE. > -Shawn Mamros > E-mail to: mamros@ftp.com > > RAJESH SALUJA   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08139; 21 Sep 95 5:36 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08135; 21 Sep 95 5:36 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa06085; 21 Sep 95 5:36 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA03039; Thu, 21 Sep 1995 05:28:15 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA06057; Thu, 21 Sep 1995 05:28:00 -0400 Received: from s.wipinfo.soft.net by sol (5.x/SMI-SVR4) id AA08984; Thu, 21 Sep 1995 05:27:50 -0400 Received: by s.wipinfo.soft.net (4.1/SMI-4.1) id AA16037; Thu, 21 Sep 95 15:00:04 IST Received: from comm10. by rolex.rnd.blr (4.1/SMI-4.1) id AA18859; Thu, 21 Sep 95 15:00:29+050 Received: from clab2. by comm10. (4.1/SMI-4.0) id AA03909; Thu, 21 Sep 95 15:10:53 IST Received: by clab2. (4.1/SMI-4.0) id AA07327; Thu, 21 Sep 95 15:10:53 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rajesh Saluja Message-Id: <9509210940.AA07327@clab2.> Subject: Re: DHCPRELEASE problem To: Jonathan Wenocur Date: Thu, 21 Sep 1995 15:10:52 +0530 (IST) Cc: DHCP MAILING LIST , Rajesh Saluja In-Reply-To: <199509202007.QAA06514@shiva-dev.shiva.com> from "Jonathan Wenocur" at Sep 20, 95 04:07:50 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text > >> Thanks for your reply. I would like to tell how this problem > >> arises. Suppose that the DHCP is being used by a remote access > >> product for giving the address to the remote end of PPP > >> connection. Once the address hasbeen acquired by the client, that > >> address is given to some remote machine. In this way, a client > >> can get so many addresses for different remote machines using > >> different client identifiers. ( I think that Shiva does that ). > >> In this situation, REBIND/RENEW is very difficult. Because > >> the response to a REBIND/RENEW is an unicast, it is difficult for > >> such a client to handle the responses to RENEW/REBIND for > >> addresses of remote machines. Moreover, it is also likely that > >> such a response will never come to the client ( i.e. the remote > >> access product where the dhcp client is running) because if the > >> server is not on the local net then it may find a shorter route > >> to send that message to the remote machine ( i.e. the machine > >> which got the address from remote access product through DHCP). > >> ( I hope that it makes sense...). > > How could this happen for a dial-in client? How is there an alternate > route to a dial-in client, shouldn't the only route be through the > remote access server it's dialed into? > I was considering the case when my remote machine is being configured as a router. Anyway, the RFC clearly says that DHCP is not intended for configuring routers. In that situation, I agree that this will never happen. > (Just as a reference point we don't allow leases longer than 48 hours > for dial-in clients. And the remote access server handles all of the > renewal stuff.) > > -- Jonathan > If the remote access server handles all of the renewal stuff, I think that it will degrade the performance. The reason is that the response to a DHCPRENEW/DHCPREBIND is a unicast message. When this message reaches the remote access server, it is not for it but only because of DHCP, this particular packet is to be handled by IP as a special case and passed to DHCP client which is sitting above UDP. If IP checks every packet just for DHCP, the performance will deteriorate. Also it will be required to do dirty IP coding. --Rajesh Saluja   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09404; 21 Sep 95 8:57 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09396; 21 Sep 95 8:57 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa09450; 21 Sep 95 8:57 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA28955; Thu, 21 Sep 1995 08:53:19 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA06416; Thu, 21 Sep 1995 08:52:26 -0400 Received: from VNET.IBM.COM by sol (5.x/SMI-SVR4) id AA09068; Thu, 21 Sep 1995 08:52:19 -0400 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6652; Thu, 21 Sep 95 08:51:48 EDT Received: by RTP (XAGENTA 4.0) id 3658; Thu, 21 Sep 1995 08:48:52 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA15406; Thu, 21 Sep 1995 08:49:20 -0400 Message-Id: <9509211249.AA15406@cichlid.raleigh.ibm.com> To: jamesg@microsoft.com Cc: host-conf@sol.eg.bucknell.edu Subject: Re: DHCPRELEASE problem In-Reply-To: Your message of "Wed, 20 Sep 1995 13:40:00 PDT." <9509202047.AA03858@itgmsm> Date: Thu, 21 Sep 1995 08:49:13 +22305558 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Narten >DHCP is not a peer-peer protocol. It's a server that has an address pool, >loaning out addresses to clients. No disagreement here. >Having an ACK on a RELEASE, seems to me to turn the concept of client / >server on its head. I'm not sure I agree. Isn't the key DHCP model that the server can't assume that clients are always there, so servers can't out-of-the-blue send something to clients and expect a response? On the other hand, when the server gets a request, it certainly assumes the client is available at that time and can send back a response. >When a client issues a RELEASE, it's giving a polite >"I'm done. Thanks for the memories. Later." The client might be being >unplugged to head on a business trip, hanging up, or moving to another >subnet, whatever. It's NOT the client's job to sit around and retry -- >waiting for its server to come back on-line! I'm not disagreeing with this. However, if the server were required to return an ACK, a client could retransmit its RELEASE a small number of times before giving up. In most cases it would get an ack right away and everything would be fine. All that the ack would do is provide a bit more robustness when the client (unexpectedly) wants to tell the DHCP server that its finished using an address. Defining a DHCP release 'ack' message doesn't necessarily imply a radical change in the client-server interaction model. Indeed, if there is a change in the underlying model, it results from the RELEASE message itself, not an ack for the message. >It's the server's job to make sure the IP address pool is managed >correctly. Right, and having a RELEASE ack would help in this regard by making it more likely that the server would learn of addresses that had been released (e.g., the first RELEASE may have been lost, and retransmitting it once delivers the packet to the server). Having a better knowledge of which addresses are actually in use would facilitate improved management of the address pool. >The server can NEVER GUARANTEE it will be around whenever a client decides >to give up its lease. Right. >That's why DHCP gives the server a recovery >mechanism -- a finite lease. If you choose to throw away this feature of >DHCP, then obviously the admin will have many of the problems associated >with static leases. Deal. Don't try to dirty up the protocol, making the >client a "partner in address pool maintenance" trying to pretend that you >can create a failsafe leasing protocol without a timeout -- it can not be >done. I am not advocating a failsafe leasing protocol. I am of the opinion, however, that having a RELEASE ack is a trivial addition to the basic protocol and does not need to change the overall client-server interaction model. If we are going to argue that a REALEASE ack is unnecessary or 'bad', many of the same arguments could be used to say the RELEASE message itself is innappropriate. Thomas   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11197; 21 Sep 95 10:56 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11193; 21 Sep 95 10:56 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa12291; 21 Sep 95 10:56 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA15016; Thu, 21 Sep 1995 10:37:33 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA10208; Thu, 21 Sep 1995 10:36:56 -0400 Received: from mercury.Sun.COM by sol (5.x/SMI-SVR4) id AA09538; Thu, 21 Sep 1995 10:36:50 -0400 Received: from East.Sun.COM by mercury.Sun.COM (Sun.COM) id HAA26212; Thu, 21 Sep 1995 07:36:31 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (5.x/SMI-5.3) id AA16471; Thu, 21 Sep 1995 10:36:24 -0400 Received: from poori.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA16331; Thu, 21 Sep 1995 10:36:24 -0400 Received: from canoepoint by poori.East.Sun.COM (5.x/SMI-SVR4) id AA03672; Thu, 21 Sep 1995 10:36:18 -0400 Date: Thu, 21 Sep 1995 10:36:18 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Carney - Sun BOS Software Message-Id: <9509211436.AA03672@poori.East.Sun.COM> To: irfan@cisco.com, jamesg@microsoft.com Subject: Re: DHCPRELEASE problem Cc: narten@vnet.ibm.com, host-conf@sol.eg.bucknell.edu X-Mailer: ProntoIP [version 2.0] Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit > > > > > I must toss my two cents in here. > > > > DHCP is not a peer-peer protocol. It's a server that has an address > pool, > > loaning out addresses to clients. > > > > Having an ACK on a RELEASE, seems to me to turn the concept of client / > > server on its head. When a client issues a RELEASE, it's giving a polite > > > "I'm done. Thanks for the memories. Later." The client might be > being > > unplugged to head on a business trip, hanging up, or moving to another > > subnet, whatever. It's NOT the client's job to sit around and retry -- > > waiting for its server to come back on-line! It's the server's job to > make > > sure the IP address pool is managed correctly. > > > > The server can NEVER GUARANTEE it will be around whenever a client decides > > > to give up its lease. That's why DHCP gives the server a recovery > > mechanism -- a finite lease. If you choose to throw away this feature > of > > DHCP, then obviously the admin will have many of the problems associated > > with static leases. Deal. Don't try to dirty up the protocol, making > the > > client a "partner in address pool maintenance" trying to pretend that you > > > can create a failsafe leasing protocol without a timeout -- it can not be > > > done. > > The gist of the proposal was that the release-ack would be optional. > For those clients (or proxy-clients) that care, this will help them > clean-up early instead of sending multiple RELEASE to be sure. Nothing > mandatory about getting an Ack, has been suggested. > > -Irfan > > > jim > I still don't see the need for an ack for RELEASE, dispite the continuing mail thread on this issue. Shorter leases manage this very well, in our experience (and our customer's). Mike Carney SunSoft PC Networking Chelmsford, MA 01824   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11656; 21 Sep 95 11:27 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11652; 21 Sep 95 11:27 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa12976; 21 Sep 95 11:27 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA21156; Thu, 21 Sep 1995 11:01:30 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA11189; Thu, 21 Sep 1995 10:59:50 -0400 Received: from VNET.IBM.COM by sol (5.x/SMI-SVR4) id AA09747; Thu, 21 Sep 1995 10:59:43 -0400 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1939; Thu, 21 Sep 95 10:59:10 EDT Received: by RTP (XAGENTA 4.0) id 3680; Thu, 21 Sep 1995 10:35:00 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA16820; Thu, 21 Sep 1995 10:35:26 -0400 Message-Id: <9509211435.AA16820@cichlid.raleigh.ibm.com> To: host-conf@sol.eg.bucknell.edu Subject: Re: DHCPRELEASE problem Date: Thu, 21 Sep 1995 10:35:17 +22305558 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Narten Just had a quick conversation with Glenn Stump down the hall and an interesting point came up. If the server were to send an ACK in response to the RELEASE, to what address would it send the ACK? By definition, once a client has sent a DHCPRELEASE, the server is free to give out that address to some other node. But that implies that the client no longer is using that address and in particular won't recognize packets sent to the just-released address. I suppose the server could broadcast its ACK (yuck). Or, the semantics of the RELEASE could be refined a bit so that RELEASE doesn't imply "release now", but "release in XXX seconds", where XXX could either be a static constant or an option included in the RELEASE message (which probably is too late to add at this time). Thomas   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11686; 21 Sep 95 11:29 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11682; 21 Sep 95 11:29 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa13025; 21 Sep 95 11:29 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA26507; Thu, 21 Sep 1995 11:23:22 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA12897; Thu, 21 Sep 1995 11:20:40 -0400 Received: from shiva-dev.shiva.com (shiva.com) by sol (5.x/SMI-SVR4) id AA09895; Thu, 21 Sep 1995 11:20:34 -0400 Received: (jhw@localhost) by shiva-dev.shiva.com (8.6.9/8.6.4) id LAA04714 for host-conf@sol.eg.bucknell.edu; Thu, 21 Sep 1995 11:20:32 -0400 Date: Thu, 21 Sep 1995 11:20:32 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jonathan Wenocur Message-Id: <199509211520.LAA04714@shiva-dev.shiva.com> To: host-conf@sol.eg.bucknell.edu Subject: Re: DHCPRELEASE problem >> > (Just as a reference point we don't allow leases longer than 48 hours >> > for dial-in clients. And the remote access server handles all of the >> > renewal stuff.) >> > >> > -- Jonathan >> > >> >> If the remote access server handles all of the renewal stuff, I think that >> it will degrade the performance. The reason is that the response to a >> DHCPRENEW/DHCPREBIND is a unicast message. When this message reaches >> the remote access server, it is not for it but only because of DHCP, >> this particular packet is to be handled by IP as a special case and >> passed to DHCP client which is sitting above UDP. If IP checks every >> packet just for DHCP, the performance will deteriorate. Also it will >> be required to do dirty IP coding. >> >> --Rajesh Saluja >> It's not necessary to check every IP packet, it's only nececcary to check the IP packets during the renewal time -- i.e. when the unicast response might come back. Since renewal is a relatively rare event during the course of a connection I don't think this is an undue burden. For exmaple, if your lease is 4 hours and your T1 is 2 hours then you only need to do some special checking of the IP packers going to the dial-in client during the short period surrounding the T1 point when the proxy client sends the renewal REQUEST and expects the ACK. Assuming the ACK comes back in a timely manner then the extra checking only happens for a few seconds out of the 2 hour period, that's not too bad. The actual code is about an extra 20 lines or so, and the use of function ptrs prevents it from being too "dirty", just swap in the special output function which does the checking and swap back the real one when you're done. -- Jonathan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18735; 21 Sep 95 18:01 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18731; 21 Sep 95 18:01 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa21934; 21 Sep 95 18:01 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA08491; Thu, 21 Sep 1995 17:37:53 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA15524; Thu, 21 Sep 1995 17:36:42 -0400 Received: from hubbub.cisco.com by sol (5.x/SMI-SVR4) id AA10346; Thu, 21 Sep 1995 17:36:36 -0400 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id OAA26163 for host-conf@sol.eg.bucknell.edu; Thu, 21 Sep 1995 14:36:21 -0700 Message-Id: <199509212136.OAA26163@hubbub.cisco.com> To: host-conf@sol.eg.bucknell.edu Subject: question Date: Thu, 21 Sep 95 14:36:20 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yakov Rekhter Folks, The following is quoted from RFC1542: "If the interface has more than one IP address logically associated with it, the relay agent SHOULD choose one IP address associated with that interface and use it consistently for all BOOTP messages it relays." Could someone explain why this restriction is necessary ? Yakov Rekhter   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19290; 21 Sep 95 19:03 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19286; 21 Sep 95 19:03 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa23124; 21 Sep 95 19:03 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA02388; Thu, 21 Sep 1995 18:52:29 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA16063; Thu, 21 Sep 1995 18:51:52 -0400 Received: from relay.hp.com by sol (5.x/SMI-SVR4) id AA10389; Thu, 21 Sep 1995 18:51:47 -0400 Received: from hpisrhw.cup.hp.com (hpindwp.cup.hp.com) by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA167083903; Thu, 21 Sep 1995 15:51:44 -0700 Received: by hpisrhw.cup.hp.com with SMTP (1.37.109.15/15.5+IOS 3.20+cup+OMrelay) id AA095113722; Thu, 21 Sep 1995 15:48:42 -0700 To: Thomas Narten Cc: host-conf@sol.eg.bucknell.edu Subject: Re: DHCPRELEASE problem In-Reply-To: Message from "Thomas Narten" of "Thu, 21 Sep 95 10:35:17." <9509211435.AA16820@cichlid.raleigh.ibm.com> Date: Thu, 21 Sep 95 15:48:42 -0700 Message-Id: <9509.811723722@hpindwp.cup.hp.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Mendonca > > If the server were to send an ACK in response to the RELEASE, to what > address would it send the ACK? By definition, once a client has sent > a DHCPRELEASE, the server is free to give out that address to some > other node. But that implies that the client no longer is using that > address and in particular won't recognize packets sent to the > just-released address. > I think you had it right the first time. When a client sends a RELEASE it means "So long thanks for the memories". If it were to not receive a ACK in a few seconds it could resend the RELEASE once or twice, or just proceed as if it had. So the ACK is only usefull to protect against a transmission error. Nothing changes if the client is not around to receive the ACK. Based on the above I'm not sure just how much value the ACK adds. Does anyone have statistics on generally how often UDP transmission errors occur as a percentage of transmitted packets?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20074; 21 Sep 95 19:52 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20070; 21 Sep 95 19:52 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa23923; 21 Sep 95 19:52 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA17725; Thu, 21 Sep 1995 19:41:34 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA16443; Thu, 21 Sep 1995 19:40:40 -0400 Received: from denali.cs.ucdavis.edu by sol (5.x/SMI-SVR4) id AA10419; Thu, 21 Sep 1995 19:40:35 -0400 Received: by denali.cs.ucdavis.edu (4.1/UCD.CS.SECLAB.Solaris1-1.0) id AA00470; Thu, 21 Sep 95 16:40:30 PDT Date: Thu, 21 Sep 95 16:40:30 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Biswaroop Guha Message-Id: <9509212340.AA00470@denali.cs.ucdavis.edu> To: host-conf@sol.eg.bucknell.edu Subject: client-type ?! Hi, In rfc 1533 (DHCP Options and BOOTP Vendor Extensions), I saw that the option 61 is meant to be the client-identifier option. However, the client is required to supply a value for its "type". It is mentioned in the rfc that the types are defined in rfc 1340. However, I did not understand what exactly does it mean by "hardware type", even after scanning the rfc1340. Would anyone throw some light on this topic ? Thanks a lot, Biswa   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20427; 21 Sep 95 20:29 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20423; 21 Sep 95 20:29 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa24460; 21 Sep 95 20:29 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA26788; Thu, 21 Sep 1995 20:16:07 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA16799; Thu, 21 Sep 1995 20:15:34 -0400 Received: from uucp7.netcom.com by sol (5.x/SMI-SVR4) id AB10442; Thu, 21 Sep 1995 20:15:32 -0400 Received: from akhnaten.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id RAA22752; Thu, 21 Sep 1995 17:01:12 -0700 Received: from akhnaten.UUCP by join.com (4.1/SMI-4.1) id AA04037; Thu, 21 Sep 95 16:22:11 PDT Received: by join.com (4.1/SMI-4.1) id AA01448; Thu, 21 Sep 95 15:51:27 PDT Date: Thu, 21 Sep 95 15:51:27 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rob Stevens Message-Id: <9509212251.AA01448@join.com> To: host-conf@sol.eg.bucknell.edu, glenroy!cisco.com!yakov@netcom.com Subject: Re: question Yakov Rekhter writes > > "If the interface has > more than one IP address logically associated with it, the relay > agent SHOULD choose one IP address associated with that interface and > use it consistently for all BOOTP messages it relays." > > Could someone explain why this restriction is necessary ? Yakov, I think the reasoning (it was discussed a long while ago, and I think at a bake-off not within host-conf but can't be sure) went as follows: It is desirable that DHCP servers not have to be familiar with details about network topology, in particular that one wire may have several logical IP nets on it. If the client is performing a discover there would be no problem. The relay agent could pick any network corresponding to one of the IP addresses configured on its interface. *But*, for a client doing a request (whether from init-reboot or as follow up to an offer) the relay agent would have to select the same network# as (a) the client had when it last booted (init-reboot: maybe that was weeks ago) or (b) the client has when it did the discover(follow-up) If these conditions are not met then the server would NAK because the client's network# would not appear to correspond to the IP address it is requesting. The other alternative is to have servers know of the (many-IP to one interface) correspondence. Clearly this complicates the task of coding a server. Rob Stevens   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20440; 21 Sep 95 20:29 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20436; 21 Sep 95 20:29 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa24466; 21 Sep 95 20:29 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA26785; Thu, 21 Sep 1995 20:16:05 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA16798; Thu, 21 Sep 1995 20:15:32 -0400 Received: from netcomsv.netcom.com (uucp7.netcom.com) by sol (5.x/SMI-SVR4) id AA10442; Thu, 21 Sep 1995 20:15:27 -0400 Received: from akhnaten.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id RAA22758; Thu, 21 Sep 1995 17:01:24 -0700 Received: from akhnaten.UUCP by join.com (4.1/SMI-4.1) id AA04051; Thu, 21 Sep 95 16:25:00 PDT Received: by join.com (4.1/SMI-4.1) id AA01456; Thu, 21 Sep 95 16:03:36 PDT Date: Thu, 21 Sep 95 16:03:36 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rob Stevens Message-Id: <9509212303.AA01456@join.com> To: host-conf@sol.eg.bucknell.edu Subject: Re: DHCPRELEASE problem Boy, This (to my mind rather small and unimportant detail about how DHCP might/should work) seems to have engendered a real Jihad. I'd like to introduce another twist which has not yet been considered. There is, as you know, no server-server protocol defined in DHCP but I believe that current thinking is that a cornerstone of such a protocol would be that the IP address pool is divided up into disjoint sets, with each server "owning" one of the sets. The situation may arise that a client which reboots may receive its lease from a server which does not own the IP address in question (because a server-server protocol is running, servers have learnt of the leases other servers have given to clients, the lease is not yet expired, and the non-owning server responded first or the owner was down or...whatever). If the client now unicasts a RELEASE it will be to a server which, unfortunately, does not have the power to release that address: only the owner of that IP address has that power. This is a problem in and of itself, and it certainly would mean that the non-owning server should not be sending an ACK in response to the RELEASE. There are similar problems in RENEW when a cleint attempts to extend a lease by unicasting to a non-owning server. Rob Stevens.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05367; 22 Sep 95 1:01 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05363; 22 Sep 95 1:01 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa02104; 22 Sep 95 1:01 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA09523; Fri, 22 Sep 1995 00:58:15 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA18588; Fri, 22 Sep 1995 00:57:36 -0400 Received: from s.wipinfo.soft.net by sol (5.x/SMI-SVR4) id AA10623; Fri, 22 Sep 1995 00:57:28 -0400 Received: by s.wipinfo.soft.net (4.1/SMI-4.1) id AA00573; Fri, 22 Sep 95 10:29:40 IST Received: from comm10. by rolex.rnd.blr (4.1/SMI-4.1) id AA03112; Fri, 22 Sep 95 10:30:05+050 Received: by comm10. (4.1/SMI-4.0) id AA01878; Fri, 22 Sep 95 10:40:31 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rajesh Saluja Message-Id: <9509220510.AA01878@comm10.> Subject: Re: client-type ?! To: Biswaroop Guha Date: Fri, 22 Sep 1995 10:40:29 +0530 (IST) Cc: host-conf@sol.eg.bucknell.edu In-Reply-To: <9509212340.AA00470@denali.cs.ucdavis.edu> from "Biswaroop Guha" at Sep 21, 95 04:40:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text > > > Hi, > > In rfc 1533 (DHCP Options and BOOTP Vendor Extensions), I saw > that the option 61 is meant to be the client-identifier option. > However, the client is required to supply a value for its "type". > It is mentioned in the rfc that the types are defined in rfc 1340. > However, I did not understand what exactly does it mean by > "hardware type", even after scanning the rfc1340. Would anyone throw > some light on this topic ? > > Thanks a lot, > Biswa > > Each hardware type has its own format of MAC address. e.g. ethernet, token ring and so on. For client identifier type, id type 1 is used for sending the MAC address itself as client identifier and id type 0 is used for sending any ASCII string. RAJESH SALUJA   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06652; 22 Sep 95 4:49 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06648; 22 Sep 95 4:49 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa04894; 22 Sep 95 4:49 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA23939; Fri, 22 Sep 1995 04:43:22 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA18968; Fri, 22 Sep 1995 04:42:52 -0400 Received: from netcomsv.netcom.com (uucp12.netcom.com) by sol (5.x/SMI-SVR4) id AA10713; Fri, 22 Sep 1995 04:42:47 -0400 Received: from akhnaten.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id BAA05672; Fri, 22 Sep 1995 01:30:32 -0700 Received: from akhnaten.UUCP by join.com (4.1/SMI-4.1) id AA05367; Fri, 22 Sep 95 01:20:26 PDT Received: by join.com (4.1/SMI-4.1) id AA01461; Thu, 21 Sep 95 16:06:19 PDT Date: Thu, 21 Sep 95 16:06:19 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rob Stevens Message-Id: <9509212306.AA01461@join.com> To: host-conf@sol.eg.bucknell.edu, glenroy!cisco.com!yakov@netcom.com Subject: Re: question One more point. Perhaps that router vendors (what about it Cisco?) would be prepared to look more deeply into the DHCP packet and, were it a REQUEST, to find what address the client is requesting and select the network IP accordingly. Rob.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08797; 22 Sep 95 9:39 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08793; 22 Sep 95 9:39 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa09075; 22 Sep 95 9:39 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA23722; Fri, 22 Sep 1995 09:35:45 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA26445; Fri, 22 Sep 1995 09:35:04 -0400 Received: from hubbub.cisco.com by sol (5.x/SMI-SVR4) id AA10852; Fri, 22 Sep 1995 09:34:59 -0400 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id GAA26824 for host-conf@sol.eg.bucknell.edu; Fri, 22 Sep 1995 06:34:57 -0700 Message-Id: <199509221334.GAA26824@hubbub.cisco.com> To: host-conf@sol.eg.bucknell.edu Subject: more DHCP questions Date: Fri, 22 Sep 95 06:34:57 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yakov Rekhter Folks, When a server receives a DHCPDISCOVER message, according to section 4.3.1 the server should choose the new address as follows: - The client's current address as recorded in the client's current binding, ELSE - The client's previous address, as recorded in the client's (now expired or released) binding... Should the above addresses (either the "current address" or the "previos address") be checked to make sure that they are on the same subnet with the BOOTP relay that forwards the message ? Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10197; 22 Sep 95 10:55 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10193; 22 Sep 95 10:55 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa10493; 22 Sep 95 10:55 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA22940; Fri, 22 Sep 1995 10:45:53 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA10084; Fri, 22 Sep 1995 10:45:18 -0400 Received: from s.wipinfo.soft.net by sol (5.x/SMI-SVR4) id AA11037; Fri, 22 Sep 1995 10:45:09 -0400 Received: by s.wipinfo.soft.net (4.1/SMI-4.1) id AA12878; Fri, 22 Sep 95 20:17:25 IST Received: from comm10. by rolex.rnd.blr (4.1/SMI-4.1) id AA22180; Fri, 22 Sep 95 20:17:48+050 Received: by comm10. (4.1/SMI-4.0) id AA06438; Fri, 22 Sep 95 20:28:14 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rajesh Saluja Message-Id: <9509221458.AA06438@comm10.> Subject: Re: more DHCP questions To: Yakov Rekhter Date: Fri, 22 Sep 1995 20:28:12 +0530 (IST) Cc: DHCP MAILING LIST In-Reply-To: <199509221334.GAA26824@hubbub.cisco.com> from "Yakov Rekhter" at Sep 22, 95 06:34:57 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text > > Folks, > > When a server receives a DHCPDISCOVER message, according to section 4.3.1 > the server should choose the new address as follows: > > - The client's current address as recorded in the client's current binding, ELSE > - The client's previous address, as recorded in the client's (now expired or > released) binding... > > Should the above addresses (either the "current address" or the "previos > address") be checked to make sure that they are on the same subnet with > the BOOTP relay that forwards the message ? > > Yakov. > IP-subnet-number is the essential part of the key for binding. The current or the previous address will be chosen only if the binding for the requesting client matches and this match will definitely fail if client has moved to some other subnet. The server gets the subnet number from the giaddr if it is not 0 i.e. if the message hasbeen forwarded by a relay agent. RAJESH SALUJA email: rsaluja@wipinfo.soft.net Best Regards ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RAJESH SALUJA | Group: Communication Phone: (00 91) 80 5588422 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extn 565/566/553 | e-mail: rsaluja@wipinfo.soft.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sr Engr, R&D, Wipro Infotech Ltd., 88 M G Road, Bangalore - 560 001, India ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | To solve the human equation | | we need to add love, subtract hatred | | multiply good and divide between truth and error| +--------------------------------------------------------+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11891; 22 Sep 95 12:07 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11887; 22 Sep 95 12:07 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa12147; 22 Sep 95 12:07 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA16355; Fri, 22 Sep 1995 11:54:42 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA10809; Fri, 22 Sep 1995 11:53:42 -0400 Received: from hubbub.cisco.com by sol (5.x/SMI-SVR4) id AA11082; Fri, 22 Sep 1995 11:53:36 -0400 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id IAA06817 for host-conf@sol.eg.bucknell.edu; Fri, 22 Sep 1995 08:53:33 -0700 Message-Id: <199509221553.IAA06817@hubbub.cisco.com> To: host-conf@sol.eg.bucknell.edu Subject: renumbering with DHCP (moderately long) Date: Fri, 22 Sep 95 08:53:33 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yakov Rekhter Folks, Appended is a rough draft of a proposal that is intended to facilitate renumbering with DHCP. Your comments would be greatly appreciated. Yakov Rekhter -----------------------------------cut here------------------------------- Host Renumbering with DHCP Motivations Host addresses may need to change for a number of reasons. For example, if the address assignment scheme is based on CIDR guidelines, when a site changes its provider hosts within the site may need to change their addresses. The intention of the mechanism described here is to allow system administrators to specify a graceful transition period during renumbering to minimize disruption caused by address changes. The proposed mechanism aims at minimizing changes to DHCP protocol. Implications on Routers (BOOTP relays) During renumbering each link (Data Link subnetwork) will be assigned multiple address prefixes (IP subnets) to cover both old and new addresses. Routers would need to be configured to (a) maintain routes to both old and new address prefixes, (b) maintain multiple addresses per interface (one address per IP subnet), and (c) should be able to distinguish between the old and the new prefixes for the purpose of annotating DHCPDISCOVER and DHCPREQUEST messages. When a router annotates a DHCPDISCOVER message, the router should annotate it (the 'giaddr' field) with the address that corresponds to the new address prefix. When a router annotates a DHCPREQUEST message that carries a non-zero 'ciaddr' field, and the IP address carried in this field is on one of the subnets associated with the interface that the message was received on, the router should annotate the message (the 'giaddr' field) with its address on that subnet. If the IP address is not on one of the subnets, the router should annotate the message (the 'giaddr' field) with the address that corresponds to the new address prefix. When a router annotates a DHCPREQUEST message that carries the 'requested IP address' option, and the IP address carried in this option is on one of the subnets associated with the interface that the message was received on, the router should annotate the message (the 'giaddr' field) its address on that subnet to . If the IP address is not on one of the subnets, the router should annotate the message (the 'giaddr' field) with the address that corresponds to the new address prefix. Note that the above represents a departure from RFC1542, which states that "If the interface has more than one IP address logically associated with it, the relay agent SHOULD choose one IP address associated with that interface and use it consistently for all BOOTP messages it relays." Implications on DHCP Servers In general a DHCP server maintains one or more blocks of addresses from which it can satisfy requests for new addresses. To facilitate renumbering it should be possible to mark some of these blocks (via configuration procedures) as 'deprecated' (we'll refer to such blocks and addresses out of such blocks as 'deprecated'). When a server receives a DHCPDISCOVER message from a client, the server chooses a network address for the requesting client. If no address is available, the server may choose to report the problem to the system administrator. Otherwise, the new address should be chosen as follows: - The client's current address as recorded in the client's current binding, and is not from a deprecated block, ELSE - The client's previous address as recorded in the client's (now expired or released) binding, if that address is in the server's pool of available addresses, is not from a deprecated block, and not already allocated, ELSE - The address requested in the 'Requested IP Address' option, if that address is valid, is not from a deprecated block, and not already allocated, ELSE - A new address allocated from non-deprecated server's blocks of available addresses; the address is selected based on the interface from which the message was received (if 'giaddr' is 0), or on the address of the relay agent that forwarded the message (if 'giaddr' is not 0, and the server has a non-deprecated block of addresses for the subnet depicted by 'giaddr'), ELSE - The client's current address as recorded in the client's current binding, ELSE - The client's previous address as recorded in the client's (now expired or released) binding, if that address is in the server's pool of available addresses, ELSE - The address requested in the 'Requested IP Address' option, if that address is valid, and not already allocated, ELSE - A new address allocated from a server's pool of available addresses; the address is selected based on the subnet from which the message was received (if 'giaddr' is 0) or on the address of the relay agent that forwarded the message ('giaddr' when not 0). The above rules aim at trying first to allocate a non-deprecated address, and if none available, follow the standard DHCP procedures. The rest of handling the DHCPDISCOVER message follows standard DHCP procedures. A DHCP server handles DHCPREQUEST messages as follows: - DHCPREQUEST generated during SELECTING state: This case could be identified by presence of a 'server identifier' option. The message is handled following standard DHCP procedures, irrespective whether the 'requested IP address' option depicts an address from a deprecated block or not. - DHCPREQUEST generated during INIT_REBOOT state: This case could be identified by absence of 'server identifier', presence of 'requested IP address', and zero in 'ciaddr'. If the IP address carried in the 'requested IP address' option depicts an address from a deprecated block, the server should send a DHCPNAK message to the client. Otherwise, the message is handled following standard DHCP procedures. - DHCPREQUEST generated during RENEWING or REBINDING state: This case could be identified by absence of 'server identifier', absence of 'requested IP address', and non-zero 'ciaddr'. If the address carried in the 'ciaddr' field belong to a deprecated block, the server should not extend the lease. In all other cases the message is handled following standard DHCP procedures. If the server does not extend the lease because the address is deprecated, the server may return the 'non-renewable' option in the DHCPACK message (this is a new option, for future use). Operational considerations During renumbering it is expected that for some period of time the site would be able to use both the old and the new addresses. We refer to this time interval as an "overlap period". DHCP servers should be set in such a way that the value of the lease time and the Rebinding Time Value option returned by the servers would allow clients to change to the new addresses by the time the old ones become invalid. The overlap period should be longer than the lease time that the DHCP servers within the site are configured with.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17045; 22 Sep 95 16:40 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17039; 22 Sep 95 16:40 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa18428; 22 Sep 95 16:40 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA23025; Fri, 22 Sep 1995 15:51:12 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA12483; Fri, 22 Sep 1995 15:49:57 -0400 Received: from watson.ibm.com by sol (5.x/SMI-SVR4) id AA11400; Fri, 22 Sep 1995 15:49:51 -0400 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9583; Fri, 22 Sep 95 15:48:43 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 7921; Fri, 22 Sep 1995 15:48:42 EDT Received: from edisto.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Fri, 22 Sep 95 15:40:10 EDT Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524) id AA17352; Fri, 22 Sep 1995 15:40:31 -0400 Message-Id: <9509221940.AA17352@edisto.watson.ibm.com> X-External-Networks: yes To: host-conf@sol.eg.bucknell.edu Subject: Re: renumbering with DHCP (moderately long) In-Reply-To: Your message of Fri, 22 Sep 95 08:53:33 PDT. <199509221553.IAA06817@hubbub.cisco.com> Date: Fri, 22 Sep 95 15:40:31 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Edie E. Gunter" >> - DHCPREQUEST generated during RENEWING or REBINDING state: >> >> This case could be identified by absence of 'server identifier', >> absence of 'requested IP address', and non-zero 'ciaddr'. If the >> address carried in the 'ciaddr' field belong to a deprecated >> block, the server should not extend the lease. In all other cases >> the message is handled following standard DHCP procedures. If >> the server does not extend the lease because the address is >> deprecated, the server may return the 'non-renewable' option in >> the DHCPACK message (this is a new option, for future use). What is the new 'non-renewable' option and why is it necessary? Today, a server can choose _not_ to renew a lease. The client can manage this. What might a client do differently given the non-renewable option in the ACK? Edie   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07476; 23 Sep 95 4:31 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07472; 23 Sep 95 4:31 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa05188; 23 Sep 95 4:30 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA11943; Sat, 23 Sep 1995 04:28:52 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA14981; Sat, 23 Sep 1995 04:28:24 -0400 Received: from s.wipinfo.soft.net by sol (5.x/SMI-SVR4) id AA11904; Sat, 23 Sep 1995 04:28:16 -0400 Received: by s.wipinfo.soft.net (4.1/SMI-4.1) id AA19788; Sat, 23 Sep 95 14:00:34 IST Received: from comm10. by rolex.rnd.blr (4.1/SMI-4.1) id AA17405; Sat, 23 Sep 95 14:00:55+050 Received: by comm10. (4.1/SMI-4.0) id AA01349; Sat, 23 Sep 95 14:11:22 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rajesh Saluja Message-Id: <9509230841.AA01349@comm10.> Subject: some DHCP issues... To: DHCP MAILING LIST Date: Sat, 23 Sep 1995 14:11:20 +0530 (IST) Cc: Rajesh Saluja X-Mailer: ELM [version 2.4 PL23] Content-Type: text Hi, Here are some issues, which I think, need some attention. Please excuse meif there is some duplication with previous discussions on this platform. 1. Why the client must use 0xffffffff as the IP broadcast address and not the directed broadcast on the local net? The argument in favour of 0xffffffff is that when the client boots, it does not know the net address. But for remote access applications, where one host may acquire more than one addresses, this constraint becomes an unnecessary burden. IMO, the server should accept both the limited broadcast and directed broadcast. 2. According to RFC1542, 5.4 says that if in BOOTREQUEST, 'ciaddr' is non-zero then irrespective of BROADCAST flag,the response (i.e. BOOTREPLY) is a unicast to 'ciaddr'. In all other cases, if BROADCAST bit is set, the server will broadcast the response. The logic is that we want to reduce the broadcasts as far as possible. Hence, the response to a RENEW/REBIND message is always a unicast. But again this becomes a problem in remote access application, where you have to disturb the IP for renewing the addresses given to remote machines. IMHO, the server should broadcast the response whenever the BROADCAST bit is set.Then this problem will vanish automatically. Let the client decide whether it wants the response as the broadcast or unicast. Does this create any problem? 3. When the client sends DHCPDECLINE, it sends 0 as the source address and this message is unicasted, while it should be broadcasted. The reason is that if this message is unicasted to a server not on the same net, it can be dropped by an intermediate gateway because of illegal source address. 4. For DHCPRELEASE, there should be an ack (as an option), as suggested by many people on this list. Any comments on these issues will be greatly appreciated. If I am missing something somewhere, please point to it. BEST REGARDS RAJESH SALUJA email: rsaluja@wipinfo.soft.net   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00459; 24 Sep 95 23:38 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00455; 24 Sep 95 23:38 EDT Received: from [134.82.7.253] by CNRI.Reston.VA.US id aa00990; 24 Sep 95 23:38 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA23501; Sun, 24 Sep 1995 23:32:37 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA20838; Sun, 24 Sep 1995 23:31:55 -0400 Received: from relay.hp.com by sol (5.x/SMI-SVR4) id AA12789; Sun, 24 Sep 1995 23:31:49 -0400 Received: from hppadan.waterloo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA083709905; Sun, 24 Sep 1995 20:31:46 -0700 Received: by hppadan.waterloo.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA261259904; Sun, 24 Sep 1995 23:31:44 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Lapp Message-Id: <199509250331.AA261259904@hppadan.waterloo.hp.com> Subject: Re: some DHCP issues... To: Rajesh Saluja Date: Sun, 24 Sep 1995 23:31:44 -0500 (EDT) Cc: host-conf@sol.eg.bucknell.edu In-Reply-To: <9509230841.AA01349@comm10.> from "Rajesh Saluja" at Sep 23, 95 02:11:20 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, > Here are some issues, which I think, need some attention. > Please excuse meif there is some duplication with previous > discussions on this platform. > > 1. Why the client must use 0xffffffff as the IP broadcast address and not > the directed broadcast on the local net? ... I could see having the text say that the all 1's address SHOULD be used with a comment explaining that the possible exception would be a "proxy client". I think it is very important that most clients not assume any knowledge of the subnet address. > IMO, the server should accept both the limited broadcast and directed > broadcast. > I'd agree with that regardless of whether the spec is changed or not. The Robustness Principle says "Be conservative in what you send. Be liberal is what you accept." So although the spec may say that the client shouldn't have sent something that doesn't mean that server, having received it, should not accept it. > 2. According to RFC1542, 5.4 says that if in BOOTREQUEST, 'ciaddr' is ... > IMHO, the server should broadcast the response whenever the BROADCAST > bit is set.Then this problem will vanish automatically. Let the client decide whether it wants the response as the broadcast or unicast. Does this > create any problem? > Although I understand your problem I feel that you should probably deal with the situation as it exists. The broadcast bit was introduced as a hack to get around an existing problem (clients that couldn't accept non-broadcast traffic until they were configured). More and more it has been creeping into other uses. Sometimes there is no other solution but to use the broadcast bit. In this case there is and I don't think we should extend the use of the broadcast bit for "convenience". At the very least you will have to face the fact that the problem won't "vanish". There are too many servers and relay agents out there now, many of which won't be upgraded for a long while, to ignore them. > 3. When the client sends DHCPDECLINE, it sends 0 as the source address and > this message is unicasted, while it should be broadcasted. The reason > is that if this message is unicasted to a server not on the same net, > it can be dropped by an intermediate gateway because of illegal source > address. > Techincally a good point but I wonder how much of a problem it really is ? Somehow I can't see a router using any precious cycles to check the source address. And any router that does drop packets based on 0 source addresses is ignoring RFC1122. Does anyone have any experience with this ? > 4. For DHCPRELEASE, there should be an ack (as an option), as suggested > by many people on this list. > While I have no objection to including an optional ACK for the DHCPRELEASE in the spec I'd point out (again :-) that you will need to take into account existing implementations (and new ones if the ACK is truely "optional"). If you can't count on the ACK being even sent what good is it ? Dave Lapp Hewlett-Packard Panacom Automation Div.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06438; 25 Sep 95 3:52 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06434; 25 Sep 95 3:52 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa04418; 25 Sep 95 3:52 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA12375; Mon, 25 Sep 1995 03:50:25 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA21581; Mon, 25 Sep 1995 03:50:10 -0400 Received: from greatdane.cisco.com by sol (5.x/SMI-SVR4) id AA12927; Mon, 25 Sep 1995 03:50:05 -0400 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id AAA04481; Mon, 25 Sep 1995 00:50:03 -0700 Date: Mon, 25 Sep 1995 00:50:03 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199509250750.AAA04481@greatdane.cisco.com> To: yakov@cisco.com Cc: host-conf@sol.eg.bucknell.edu In-Reply-To: <199509221553.IAA06817@hubbub.cisco.com> (message from Yakov Rekhter on Fri, 22 Sep 95 08:53:33 PDT) Subject: Re: renumbering with DHCP (moderately long) Please pardon the naive questions: When a router annotates a DHCPREQUEST message that carries a non-zero 'ciaddr' field, and the IP address carried in this field is on one of the subnets associated with the interface that the message was received on, the router should annotate the message (the 'giaddr' field) with its address on that subnet. If the IP address is not on one of the subnets, the router should annotate the message (the 'giaddr' field) with the address that corresponds to the new address prefix. If a request has a non-zero 'ciaddr' field, and is NOT broadcast, then the DHCP relay agent should simply forward the packet and not relay it. Why would the client ever want to broadcast a request in the case where it already has a server's address and it has a legit address already? There's also a bad assumption here that there's only ONE new address prefix. When a router annotates a DHCPREQUEST message that carries the 'requested IP address' option, and the IP address carried in this option is on one of the subnets associated with the interface that the message was received on, the router should annotate the message (the 'giaddr' field) its address on that subnet to . If I understand this, the relay agent is now required to parse the DHCP extensions... ;-( Note that the above represents a departure from RFC1542, which states that "If the interface has more than one IP address logically associated with it, the relay agent SHOULD choose one IP address associated with that interface and use it consistently for all BOOTP messages it relays." Which is what's deployed today.... ;-( I would suggest that perhaps a better approach is that the giaddr be filled with one address from the interface; that the server be configured to know all prefixes on that particular media; and that the server know which prefixes are deprecated. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15702; 25 Sep 95 14:40 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15698; 25 Sep 95 14:40 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa17551; 25 Sep 95 14:36 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA23820; Mon, 25 Sep 1995 14:30:21 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA25958; Mon, 25 Sep 1995 14:29:45 -0400 Received: from relay.hp.com by sol (5.x/SMI-SVR4) id AA13389; Mon, 25 Sep 1995 14:29:39 -0400 Received: from hppadan.waterloo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA253563775; Mon, 25 Sep 1995 11:29:36 -0700 Received: by hppadan.waterloo.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA095013774; Mon, 25 Sep 1995 14:29:34 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Lapp Message-Id: <199509251829.AA095013774@hppadan.waterloo.hp.com> Subject: Re: renumbering with DHCP (moderately long) To: Yakov Rekhter Date: Mon, 25 Sep 1995 14:29:34 -0500 (EDT) Cc: host-conf@sol.eg.bucknell.edu, David Lapp In-Reply-To: <199509221553.IAA06817@hubbub.cisco.com> from "Yakov Rekhter" at Sep 22, 95 08:53:33 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit (I seem to have done something wrong in my first attempt to send this. My appologies if it did go out successfully and you've seen it before.) Hi, It seems to me that most of the changes in this proposal are aimed at maintaining leases for both old and new addresses concurrently until the leases for the old addresses expire. It isn't clear to me why this is important. What have I missed ? The protocol permits the server to NAK a client at both RENEW and REBIND times if the address that the client is using is not appropriate for the subnet that it is on. This forces the client to enter INIT state and acquire a new address. This is the same outcome as a lease expiry. Most of us think of this mechanism being used when a client is moved from one subnet to another without reinitializing. (e.g. I unplug the ethernet from my workstation and plug in another ethernet on a different subnet.) I believe that this mechanism can be used as part of a renumbering scheme using DHCP. What I have in mind works in the following manner: 1) start by configuring your routers to have a second address on the new network on each interface. 2) the relay agents should still be configured to use the old addresses in the giaddar field of forwarded packets. (Exactly how this is controlled is implementation dependent but I suspect that most routers with relay agents use the "first" or "primary" IP address for an interface.) 3) although it has nothing to do with DHCP you probably want to change the configuration of manually configured hosts. If they support more then one IP address per interface you may be able to have both new and old addresses configured to ease the transition. 4) configure your DHCP server(s) to have appropriate pools of new addresses for all the subnets. Remove the address pools for the old addresses and delete the binding database(s). (Exactly how this is achieved is implementation dependent. Some servers may have controls/commands that allow this. Others may require that the server be stopped, the config file(s) overwriten, the database(s) removed, and the server restarted. For still others it may be easier to configure the new address pools for a DHCP server on a second machine and then stop the original server. It may require some extraordinary measures. But then renumbering is hopefully an extraordinary occurance.) The server(s) won't start assigning addresses from the new pools until it/they start seeing requests that either have appropriate giaddr's or come in thru interfaces configured with the new addresses. 5) you now start the transition period for DHCP clients a:Reconfigure your DHCP server(s) to assign addresses for directly connected subnet(s) from the new pool(s). (Again exactly how this is done is implementation dependent. Most servers base their choice of pool on the IP address of the interface on which the request was received. So it may involve manually changing the IP address or, if the DHCP server host has multiple addresses per interface, it may involve changing the order of the addresses configured for the interface.) b:Reconfigure the relay agents to use the new network numbers for giaddr on packets that they forward. If the relay agents are not router based you may also need to manually reconfigure their IP address and routing information. On each subnet, as either the directly connected DHCP server or the relay agent is reconfigured, the DHCP clients will begin to enter INIT state and reconfigure. At the worst case they should all have been forced into INIT state by the REBINDing time (T2) after the server/relay agent are reconfigured. The server(s) will NAK the clients a soon as it sees a DHCPREQUEST which (the server believes) indicates that the client is using an invalid IP address. For clients on the same subnet as the server this is probably at RENEW (T1) time. For clients on the other side of relay agents this is at REBIND (T2) time. I believe that this scheme supports renumbering without changes to existing relay agents and DHCP clients and in general without changes to existing servers. > The intention of the mechanism described here is to allow system > administrators to specify a graceful transition period during > renumbering to minimize disruption caused by address changes. > It seems to me that the "gracefullness" of the transition is limited by a couple of factors. One is the inability to change the address of either endpoint in an IP "connection" once the connection is established. The other is that DHCP supports only the configuration of one address per interface. So even for hosts that are manually configured and that support multiple addresses per interface there will (possibly) be some disruption in communications during a renumbering. For hosts configured with DHCP and those manually configured hosts which don't support multiple addresses per interface the disruption is even more complete. I think that the best that we can do is provide a means to control the timing of the disruption. Dave Lapp Hewlett-Packard Co. Panacom Automation Div.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16463; 25 Sep 95 15:19 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16459; 25 Sep 95 15:19 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa18469; 25 Sep 95 15:15 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA02533; Mon, 25 Sep 1995 15:03:37 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA26212; Mon, 25 Sep 1995 15:02:14 -0400 Received: from watson.ibm.com by sol (5.x/SMI-SVR4) id AA13415; Mon, 25 Sep 1995 15:02:09 -0400 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8293; Mon, 25 Sep 95 15:01:03 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 0367; Mon, 25 Sep 1995 15:01:03 EDT Received: from edisto.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Mon, 25 Sep 95 15:01:01 EDT Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524) id AA12063; Mon, 25 Sep 1995 15:01:25 -0400 Message-Id: <9509251901.AA12063@edisto.watson.ibm.com> X-External-Networks: yes To: host-conf@sol.eg.bucknell.edu Subject: Re: renumbering with DHCP (moderately long) In-Reply-To: Your message of Mon, 25 Sep 95 14:29:34 EST. <199509251829.AA095013774@hppadan.waterloo.hp.com> Date: Mon, 25 Sep 95 15:01:24 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Edie E. Gunter" > The other is that DHCP supports only the configuration > of one address per interface. This may be true if you use the hardware address as the client ID. But, if you use something else for the client id, there seems to be no reason why DHCP can't support multiple addresses per interface. I've done this and it seems to work fine... I'm not sure how/if this affects the renumbering scheme you laid out, though. Edie   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16942; 25 Sep 95 15:41 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16938; 25 Sep 95 15:41 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa18930; 25 Sep 95 15:37 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA07737; Mon, 25 Sep 1995 15:25:48 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA26337; Mon, 25 Sep 1995 15:24:42 -0400 Received: from hp.com by sol (5.x/SMI-SVR4) id AA13436; Mon, 25 Sep 1995 15:24:35 -0400 Received: from hppadan.waterloo.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA205477056; Mon, 25 Sep 1995 12:24:17 -0700 Received: by hppadan.waterloo.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA178497056; Mon, 25 Sep 1995 15:24:16 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Lapp Message-Id: <199509251924.AA178497056@hppadan.waterloo.hp.com> Subject: Re: renumbering with DHCP (moderately long) To: "Edie E. Gunter" Date: Mon, 25 Sep 1995 15:24:16 -0500 (EDT) Cc: host-conf@sol.eg.bucknell.edu In-Reply-To: <9509251901.AA12063@edisto.watson.ibm.com> from "Edie E. Gunter" at Sep 25, 95 03:01:24 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > > The other is that DHCP supports only the configuration > > of one address per interface. > > This may be true if you use the hardware address as the client > ID. But, if you use something else for the client id, > there seems to be no reason why DHCP can't support multiple > addresses per interface. I've done this and it seems to work > fine... I'm not sure how/if this affects the renumbering > scheme you laid out, though. > Yes I hadn't considered that. With some client changes (but probably no protocol changes) it might be possible to make use of this. Dave Lapp HP Panacom   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06901; 26 Sep 95 2:48 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06897; 26 Sep 95 2:48 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa03760; 26 Sep 95 2:48 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA27089; Tue, 26 Sep 1995 02:49:53 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA01007; Tue, 26 Sep 1995 02:49:22 -0400 Received: from netcomsv.netcom.com (uucp8.netcom.com) by sol (5.x/SMI-SVR4) id AA13857; Tue, 26 Sep 1995 02:49:17 -0400 Received: from akhnaten.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id XAA15175; Mon, 25 Sep 1995 23:31:58 -0700 Received: from akhnaten.UUCP by join.com (4.1/SMI-4.1) id AA21948; Mon, 25 Sep 95 23:23:43 PDT Received: by join.com (4.1/SMI-4.1) id AA05079; Mon, 25 Sep 95 21:45:11 PDT Date: Mon, 25 Sep 95 21:45:11 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rob Stevens Message-Id: <9509260445.AA05079@join.com> To: host-conf@sol.eg.bucknell.edu Subject: 255.255.255.255 vs directed broadcast Excerpt from exchange between Rajesh Saluja(>>) and Dave Lapp (>) > > 1. Why the client must use 0xffffffff as the IP broadcast address and not > > the directed broadcast on the local net? > ... > > I could see having the text say that the all 1's address SHOULD > be used with a comment explaining that the possible exception would be > a "proxy client". I think it is very important that most clients > not assume any knowledge of the subnet address. > > > IMO, the server should accept both the limited broadcast and directed > > broadcast. > > > I'd agree with that regardless of whether the spec is changed > or not. The Robustness Principle says "Be conservative in what > you send. Be liberal is what you accept." > > So although the spec may say that the client shouldn't have > sent something that doesn't mean that server, having received it, > should not accept it. True, but this provision was not made due to the unwillingness of servers to accept a directed broadcast (which would not be logical) but because at least some commercial routers will not relay a directed broadcast: they will relay only a limited broadcast. See my posting to this group of Oct 15, '94. The particular router with which we had a problem was a Cisco (model unknown) running release 9.x. Please note that I don't think that this was incorrect behavior for the relay agent. Bootp relay agents have been around for a few millenia, and DHCP clients (proxy or otherwise) for the twinkling of an eye, so I believe it is up to the DHCP people to conform to this requirement. It makes no difference whether the client is proxy or real. Would some knowlegeable person from Cisco (and other router vendors) please comment on this issue as regards particular releases of their software. Rob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08222; 26 Sep 95 6:39 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08216; 26 Sep 95 6:39 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa06880; 26 Sep 95 6:39 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA17034; Tue, 26 Sep 1995 06:38:15 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA02152; Tue, 26 Sep 1995 06:36:20 -0400 Received: from coral.bucknell.edu by sol (5.x/SMI-SVR4) id AA13925; Tue, 26 Sep 1995 06:36:16 -0400 Received: from uvite54.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA16944; Tue, 26 Sep 1995 06:36:11 -0400 Date: Tue, 26 Sep 1995 06:36:11 -0400 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Re: DHCPRELEASE problem Typically, a client issuing a DHCPRELEASE is in the process of shutting down, and the user sitting in front of that client is not likely to want to wait for a couple of minutes of timeout if there is a problem receiving an ack... There is an alternative to depending on infinite leases and DHCPRELEASE; perhaps this alternative should be explicitly mentioned in the protocol spec? And, while there is a potential cost to the netadmin in retrieving unused addresses that hav enot been successfully RELEASED, I don't think the problem will happen often nor is the cost high enough to warrant changing the protocol at this point. As was pointed out, by the time the server sends an ACK, the client has released (and cannot use) the address. The protocol could be changed so that a DHCPRELEASE indicates that the client will release the address as soon as the ACK is received (or a timeout expires). Weighing the alternatives, I think we shouldn't add a requirement for an ACK to a DHCPRELEASE, and we should leave the protocol spec unchanged... - Ralph   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08229; 26 Sep 95 6:39 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08221; 26 Sep 95 6:39 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa06885; 26 Sep 95 6:39 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA17055; Tue, 26 Sep 1995 06:38:28 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA02153; Tue, 26 Sep 1995 06:36:30 -0400 Received: from coral.bucknell.edu by sol (5.x/SMI-SVR4) id AA13928; Tue, 26 Sep 1995 06:36:25 -0400 Received: from uvite54.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA16952; Tue, 26 Sep 1995 06:36:21 -0400 Date: Tue, 26 Sep 1995 06:36:21 -0400 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Re: some DHCP issues... At 11:31 PM 9/24/95, David Lapp wrote: >> 1. Why the client must use 0xffffffff as the IP broadcast address and not >> the directed broadcast on the local net? >... > >I could see having the text say that the all 1's address SHOULD >be used with a comment explaining that the possible exception would be >a "proxy client". I think it is very important that most clients >not assume any knowledge of the subnet address. Agreed - the client shouldn't make any assumptions about the local subnet. What would be the advantage of using the directed broadcast address instead of the all 1s address? >> 2. According to RFC1542, 5.4 says that if in BOOTREQUEST, 'ciaddr' is >... >> IMHO, the server should broadcast the response whenever the BROADCAST >> bit is set.Then this problem will vanish automatically. Let the client >> decide whether it wants the response as the broadcast or unicast. Does >> this create any problem? >> >Although I understand your problem I feel that you should probably >deal with the situation as it exists. The broadcast bit was introduced >as a hack to get around an existing problem (clients that couldn't >accept non-broadcast traffic until they were configured). Agreed - we should limit the use of the BROADCAST bit as much as possible. Does anyone have a sense of how many router vendors (and installed routers) now implement the BROADCAST bit? - Ralph   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17442; 26 Sep 95 18:45 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17438; 26 Sep 95 18:45 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa22944; 26 Sep 95 18:45 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA11108; Tue, 26 Sep 1995 18:39:50 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA22965; Tue, 26 Sep 1995 18:39:04 -0400 Received: from brid (brid.its.utas.edu.au) by sol (5.x/SMI-SVR4) id AA15065; Tue, 26 Sep 1995 18:38:58 -0400 Received: from pc11 (pc11.its.utas.edu.au [144.6.19.4]) by brid (8.6.12/8.6.12) with SMTP id IAA15098 for ; Wed, 27 Sep 1995 08:38:47 +1000 Date: Wed, 27 Sep 1995 08:38:47 +1000 Message-Id: <199509262238.IAA15098@brid> X-Sender: pcoles@postoffice.newnham.utas.edu.au X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Phillip Coles Subject: unsubscribe Please unsubscribe Phillip.Coles@its.utas.edu.au ----------------------------------------------------------------------------- Phillip Coles, B.App.Comp. Email: Phillip.Coles@its.utas.edu.au Network Assistant Ph.: +61 03 24 3219 Information Technology Services (Newnham) Fax: +61 03 24 3081 University of Tasmania Mobile: Not even close P.O. Box 1214, Launceston, Tas. 7250, Australia _____________________________________________________________________________   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06821; 27 Sep 95 7:07 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06817; 27 Sep 95 7:07 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa07002; 27 Sep 95 7:07 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA01999; Wed, 27 Sep 1995 07:02:52 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA25488; Wed, 27 Sep 1995 07:01:56 -0400 Received: from coral.bucknell.edu by sol (5.x/SMI-SVR4) id AA15336; Wed, 27 Sep 1995 07:01:52 -0400 Received: from uvite55.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA00662; Wed, 27 Sep 1995 07:01:48 -0400 Date: Wed, 27 Sep 1995 07:01:48 -0400 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Re: DHCPRELEASE problem At 4:03 PM 9/21/95, Rob Stevens wrote: >There is, as you know, no server-server protocol defined in DHCP >but I believe that current thinking is that a cornerstone of such >a protocol would be that the IP address pool is divided up into >disjoint sets, with each server "owning" one of the sets. > >The situation may arise that a client which reboots may receive >its lease from a server which does not own the IP address in >question [...] > >If the client now unicasts a RELEASE it will be to a server which, >unfortunately, does not have the power to release that address: >only the owner of that IP address has that power. This is a >problem in and of itself, and it certainly would mean that the >non-owning server should not be sending an ACK in response to >the RELEASE. > >There are similar problems in RENEW when a client attempts to extend >a lease by unicasting to a non-owning server. These two problems - and a host of other related distributed database consistency problems - all make the design and definition of a server-server model and protocol a hard problem. For example, suppose a client successfully releases its address to the owning server, and then asks for another address before the release notification has propagated to the non-owning servers. The client will receive an offer for a new lease from the owning server and the old lease from the non-owning server. - Ralph   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12644; 28 Sep 95 12:26 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12639; 28 Sep 95 12:26 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa14833; 28 Sep 95 12:26 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA05497; Thu, 28 Sep 1995 12:04:14 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA02092; Thu, 28 Sep 1995 12:03:06 -0400 Received: from hubbub.cisco.com by sol (5.x/SMI-SVR4) id AA16309; Thu, 28 Sep 1995 12:03:00 -0400 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id JAA23668; Thu, 28 Sep 1995 09:02:52 -0700 Message-Id: <199509281602.JAA23668@hubbub.cisco.com> To: Tony Li Cc: host-conf@sol.eg.bucknell.edu Subject: Re: renumbering with DHCP (moderately long) In-Reply-To: Your message of "Mon, 25 Sep 95 00:50:03 PDT." <199509250750.AAA04481@greatdane.cisco.com> Date: Thu, 28 Sep 95 09:02:52 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yakov Rekhter Tony, > Please pardon the naive questions: > > When a router annotates a DHCPREQUEST message that carries > a non-zero 'ciaddr' field, and the IP address carried in this field is > on one of the subnets associated with the interface that the > message was received on, the router should annotate the message > (the 'giaddr' field) with its address on that subnet. If the IP > address is not on one of the subnets, the router should annotate the > message (the 'giaddr' field) with the address that corresponds to > the new address prefix. > > If a request has a non-zero 'ciaddr' field, and is NOT broadcast, then > the DHCP relay agent should simply forward the packet and not relay > it. That is certainly correct. The above text assumes that the request is a broadcast. > Why would the client ever want to broadcast a request in the case > where it already has a server's address and it has a legit address > already? A client may do it when it is in REBINDING state. Quoting from the latest I-D (section 4.3.2) "This message MUST be broadcast to the 0xffffffff IP broadcast address." > There's also a bad assumption here that there's only ONE new address > prefix. If there is more than one prefix, the BOOTP relay may annotate REQUEST with any of the new prefixes. Note that *in principle* one could consider annotating DHCPREQUEST with multiple prefixes, but to make this useful I suspect this would require substantial surgery to DHCP. > > When a router annotates a DHCPREQUEST message that carries the > 'requested IP address' option, and the IP address carried in this > option is on one of the subnets associated with the interface that > the message was received on, the router should annotate the > message (the 'giaddr' field) its address on that subnet to . > > If I understand this, the relay agent is now required to parse the > DHCP extensions... ;-( That is correct. > Note that the above represents a departure from RFC1542, which > states that "If the interface has more than one IP address logically > associated with it, the relay agent SHOULD choose one IP address > associated with that interface and use it consistently for all BOOTP > messages it relays." > > Which is what's deployed today.... ;-( > > I would suggest that perhaps a better approach is that the giaddr be > filled with one address from the interface; that the server be configured > to know all prefixes on that particular media; and that the server > know which prefixes are deprecated. > One problem with your suggestion is that if routers on "that particular media" are not (yet) configured to advertise new prefixes, and the server returns an address out of a new prefix, the host (that would accept this address) would become unreachable. To restate this, your suggestion introduces an additional dependency -- all the routers within a site that has to be renumbered have to be configured with both new and old addresses *prior* to configuring DHCP servers within the site with new and old addresses. Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13220; 28 Sep 95 13:00 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13216; 28 Sep 95 13:00 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa15444; 28 Sep 95 13:00 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA16714; Thu, 28 Sep 1995 12:43:11 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA02360; Thu, 28 Sep 1995 12:42:39 -0400 Received: from hubbub.cisco.com by sol (5.x/SMI-SVR4) id AA16340; Thu, 28 Sep 1995 12:42:32 -0400 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id JAA26926; Thu, 28 Sep 1995 09:42:29 -0700 Message-Id: <199509281642.JAA26926@hubbub.cisco.com> To: "Edie E. Gunter" Cc: host-conf@sol.eg.bucknell.edu Subject: Re: renumbering with DHCP (moderately long) In-Reply-To: Your message of "Fri, 22 Sep 95 15:40:31 CDT." <9509221940.AA17352@edisto.watson.ibm.com> Date: Thu, 28 Sep 95 09:42:29 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yakov Rekhter Edie, > >> - DHCPREQUEST generated during RENEWING or REBINDING state: > >> > >> This case could be identified by absence of 'server identifier', > >> absence of 'requested IP address', and non-zero 'ciaddr'. If the > >> address carried in the 'ciaddr' field belong to a deprecated > >> block, the server should not extend the lease. In all other cases > >> the message is handled following standard DHCP procedures. If > >> the server does not extend the lease because the address is > >> deprecated, the server may return the 'non-renewable' option in > >> the DHCPACK message (this is a new option, for future use). > > What is the new 'non-renewable' option and why is it necessary? > Today, a server can choose _not_ to renew a lease. The client > can manage this. What might a client do differently given the > non-renewable option in the ACK? I wasn't sure how necessary this option would be (that is why I said "for future use"). One possible "future use" that I can imagine is that when a client receives the ACK with this option, the client would immediately initialize another DHCP FSM to acquire a new address (without waiting till the old address would expire). But of course, you may say that the client can do this even without the option, by noticing that the server didn't extend the lease. So, you may argue that the option is not needed. Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14394; 28 Sep 95 13:55 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14387; 28 Sep 95 13:55 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa16536; 28 Sep 95 13:55 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA08326; Thu, 28 Sep 1995 13:52:53 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA02796; Thu, 28 Sep 1995 13:52:20 -0400 Received: from hubbub.cisco.com by sol (5.x/SMI-SVR4) id AA16405; Thu, 28 Sep 1995 13:52:14 -0400 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id KAA04013; Thu, 28 Sep 1995 10:50:51 -0700 Message-Id: <199509281750.KAA04013@hubbub.cisco.com> To: David Lapp Cc: host-conf@sol.eg.bucknell.edu Subject: Re: renumbering with DHCP (moderately long) In-Reply-To: Your message of "Mon, 25 Sep 95 14:29:34 CDT." <199509251829.AA095013774@hppadan.waterloo.hp.com> Date: Thu, 28 Sep 95 10:50:51 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yakov Rekhter Dave, > It seems to me that most of the changes in this proposal are > aimed at maintaining leases for both old and new addresses > concurrently until the leases for the old addresses expire. Letting the old address expire was one aim. Another aim was to minimize the amount of inter-dependencies during renumbering. > It isn't clear to me why this is important. What have I missed ? For one thing, if a host could maintain both old and new addresses, the host may continue to use old addresses for existing transport connections, while using new addresses for new transport connection. This would minimize transport connection disruption during renumbering. Note, that this is pretty much the same as the notion of "deprecated" addresses in IPv6; the same notion could be applied to IPv4 as well. > What I have in mind works > in the following manner: > > 1) start by configuring your routers to have a second address > on the new network on each interface. Fine. > > 2) the relay agents should still be configured to use the old > addresses in the giaddar field of forwarded packets. Fine too. [deleted] > 4) configure your DHCP server(s) to have appropriate pools of > new addresses for all the subnets. Remove the address pools > for the old addresses and delete the binding database(s). > (Exactly how this is achieved is implementation dependent. > Some servers may have controls/commands that allow this. > Others may require that the server be stopped, the config > file(s) overwriten, the database(s) removed, and the server > restarted. For still others it may be easier to configure the > new address pools for a DHCP server on a second machine and > then stop the original server. It may require some extraordinary > measures. But then renumbering is hopefully an extraordinary > occurance.) The server(s) won't start assigning addresses from > the new pools until it/they start seeing requests that either > have appropriate giaddr's or come in thru interfaces configured > with the new addresses. > > 5) you now start the transition period for DHCP clients > a:Reconfigure your DHCP server(s) to assign addresses > for directly connected subnet(s) from the new pool(s). > (Again exactly how this is done is implementation dependent. > Most servers base their choice of pool on the IP address > of the interface on which the request was received. So it > may involve manually changing the IP address or, if the > DHCP server host has multiple addresses per interface, it > may involve changing the order of the addresses configured > for the interface.) > b:Reconfigure the relay agents to use the new network numbers > for giaddr on packets that they forward. If the relay agents > are not router based you may also need to manually reconfigure > their IP address and routing information. > What would happen when you remove the address pools for the old addresses on all the DHCP servers within your site (completed step 4), but didn't yet reconfigure the relay agents to use the new network numbers (as this reconfiguration is going to happen in step 5) ? Specifically, how would a host acquire its address during the time interval between step 4 and step 5 ? Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15974; 28 Sep 95 15:36 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15970; 28 Sep 95 15:36 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa18837; 28 Sep 95 15:36 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA08731; Thu, 28 Sep 1995 15:34:47 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA03921; Thu, 28 Sep 1995 15:33:54 -0400 Received: from gateway.ey.com by sol (5.x/SMI-SVR4) id AA16508; Thu, 28 Sep 1995 15:33:43 -0400 Received: from USEMX@US.EY.COM (ey.com) by gateway.ey.com with SMTP id AA16616 (InterLock SMTP Gateway 3.0 for ); Thu, 28 Sep 1995 15:32:07 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jeffrey.Ross@ey.com X400-Originator: Jeffrey.Ross@EY.COM X400-Recipients: host-conf@sol.eg.bucknell.edu X400-Mts-Identifier: [/PRMD=ERNSTYOUNG/ADMD=ATTMAIL/C=US/;0014500001679414000004] X400-Content-Type: P2-1988 (22) Message-Id: <0014500001679414000004*@MHS> To: "host-conf(a)sol.eg.bucknell.edu" Subject: subscribe Date: Thu, 28 Sep 1995 15:40:32 -0400 subscribe jeffrey.ross@ey.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16875; 28 Sep 95 16:17 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16871; 28 Sep 95 16:17 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa19922; 28 Sep 95 16:17 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA18670; Thu, 28 Sep 1995 16:09:11 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA04447; Thu, 28 Sep 1995 16:08:02 -0400 Received: from metronet.com (feenix.metronet.com) by sol (5.x/SMI-SVR4) id AA16602; Thu, 28 Sep 1995 16:07:55 -0400 Received: from newt.hmhs.com (eul181.metronet.com) by metronet.com with SMTP id AA10746 (5.67a/IDA1.5hp for ); Thu, 28 Sep 1995 15:06:42 -0500 Date: Thu, 28 Sep 1995 15:06:42 -0500 Message-Id: <199509282006.AA10746@metronet.com> X-Sender: dbstewa@metronet.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Rob Stevens Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "David B. Stewart" Subject: Re: 255.255.255.255 vs directed broadcast Cc: host-conf@sol.eg.bucknell.edu Rob, I'm neither a router vendor or Cisco employee. Just a Cisco customer that fought a similar battle a few months back. During the chit-chat with a cisco developer it was explained to me that Cisco forwarding policy, irrespective of software version, is to forward _only_ major net host bcasts and all-ones. Net directed bcasts are not to be forwarded. Why this was set in stone was never made clear. It just was and I needed to accept the fact. In fact, with the problem I experienced, there was a loophole that allowed net directed bcasts through (bench verified by me on C/7000 with v10.0(5) & v10.0(8) firmware.) I highly suspect the loophole has always been there and still is. It only seemed to work if both IP routing and bridging were enabled and a valid route to the directed net was present. IP routing alone did not provide the loop hole. Regarding BOOTP bcasts, I have seen net directed bcasts work just fine with cisco firmware as old as v8.1(x)on all MGS & AGS+ models. They got passed right thru the router(s) without hindrance. We booted remote X-stations this way at some sites. My $0.02. ;-) -Dave At 09:45 PM 9/25/95 PDT, you wrote: > >True, but this provision was not made due to the unwillingness >of servers to accept a directed broadcast (which would not be logical) >but because at least some commercial routers will not relay >a directed broadcast: they will relay only a limited broadcast. > >See my posting to this group of Oct 15, '94. The particular router >with which we had a problem was a Cisco (model unknown) running release 9.x. >Please note that I don't think that this was incorrect behavior for the relay >agent. Bootp relay agents have been around for a few millenia, and DHCP >clients (proxy or otherwise) for the twinkling of an eye, so I believe >it is up to the DHCP people to conform to this requirement. It makes >no difference whether the client is proxy or real. > > >Would some knowlegeable person from Cisco (and other router vendors) >please comment on this issue as regards particular releases of their >software. > >Rob > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19061; 28 Sep 95 17:42 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19057; 28 Sep 95 17:42 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa21854; 28 Sep 95 17:42 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA12135; Thu, 28 Sep 1995 17:33:08 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA05056; Thu, 28 Sep 1995 17:32:45 -0400 Received: from greatdane.cisco.com by sol (5.x/SMI-SVR4) id AA16677; Thu, 28 Sep 1995 17:32:40 -0400 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id OAA03428; Thu, 28 Sep 1995 14:32:28 -0700 Date: Thu, 28 Sep 1995 14:32:28 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199509282132.OAA03428@greatdane.cisco.com> To: yakov@cisco.com Cc: host-conf@sol.eg.bucknell.edu In-Reply-To: <199509281602.JAA23668@hubbub.cisco.com> (message from Yakov Rekhter on Thu, 28 Sep 95 09:02:52 PDT) Subject: Re: renumbering with DHCP (moderately long) When a router annotates a DHCPREQUEST message that carries a non-zero 'ciaddr' field, and the IP address carried in this field is on one of the subnets associated with the interface that the message was received on, the router should annotate the message (the 'giaddr' field) with its address on that subnet. A client may do it when it is in REBINDING state. Quoting from the latest I-D (section 4.3.2) "This message MUST be broadcast to the 0xffffffff IP broadcast address." However, in such a case when the host is rebinding, it would seem that this would be a PRIME opportunity to renumber the host. Shouldn't the forwarding agent annotate the request with its address from one of the new prefixes? This simplifies the forwarding agent in that it always annotates any broadcast with the new address. > There's also a bad assumption here that there's only ONE new address > prefix. If there is more than one prefix, the BOOTP relay may annotate REQUEST with any of the new prefixes. Note that *in principle* one could consider annotating DHCPREQUEST with multiple prefixes, but to make this useful I suspect this would require substantial surgery to DHCP. Agreed, however, the text should be more general. I believe it's reasonable to request an annotation from ONE of the new prefixes. It's necessary for the network manager to designate at least one prefix as "new" in this case. One problem with your suggestion is that if routers on "that particular media" are not (yet) configured to advertise new prefixes, and the server returns an address out of a new prefix, the host (that would accept this address) would become unreachable. To restate this, your suggestion introduces an additional dependency -- all the routers within a site that has to be renumbered have to be configured with both new and old addresses *prior* to configuring DHCP servers within the site with new and old addresses. You overstate the dependency: it is only necessary that all routers for a prefix be configured with a prefix before the DHCP server allocate addresses from that prefix. Thus, the chain of events is: ... n) Apply new prefix to routers. n+1) Add new prefix to DHCP server. ... Again, this is NOT network wide. It can be done on a per-media basis. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19727; 28 Sep 95 18:36 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19723; 28 Sep 95 18:36 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa22981; 28 Sep 95 18:36 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA20232; Thu, 28 Sep 1995 18:37:37 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA05474; Thu, 28 Sep 1995 18:37:12 -0400 Received: from hubbub.cisco.com by sol (5.x/SMI-SVR4) id AA16716; Thu, 28 Sep 1995 18:37:07 -0400 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id PAA00858; Thu, 28 Sep 1995 15:37:04 -0700 Message-Id: <199509282237.PAA00858@hubbub.cisco.com> To: Tony Li Cc: host-conf@sol.eg.bucknell.edu Subject: Re: renumbering with DHCP (moderately long) In-Reply-To: Your message of "Thu, 28 Sep 95 14:32:28 PDT." <199509282132.OAA03428@greatdane.cisco.com> Date: Thu, 28 Sep 95 15:37:04 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yakov Rekhter > A client may do it when it is in REBINDING state. Quoting from the latest > I-D (section 4.3.2) "This message MUST be broadcast to the 0xffffffff IP > broadcast address." > > However, in such a case when the host is rebinding, it would seem that > this would be a PRIME opportunity to renumber the host. Shouldn't the > forwarding agent annotate the request with its address from one of the > new prefixes? This simplifies the forwarding agent in that it always > annotates any broadcast with the new address. If we're to force renumbering in the REBINDING state, then certainly we could always annotate DHCPREQUEST with the "new" giaddr. > > There's also a bad assumption here that there's only ONE new address > > prefix. > > If there is more than one prefix, the BOOTP relay may annotate REQUEST > with any of the new prefixes. Note that *in principle* one could consider > annotating DHCPREQUEST with multiple prefixes, but to make this useful > I suspect this would require substantial surgery to DHCP. > > Agreed, however, the text should be more general. I believe it's > reasonable to request an annotation from ONE of the new prefixes. > It's necessary for the network manager to designate at least one > prefix as "new" in this case. Sure. > > One problem with your suggestion is that if routers on "that > particular media" are not (yet) configured to advertise new > prefixes, and the server returns an address out of a new prefix, > the host (that would accept this address) would become > unreachable. To restate this, your suggestion introduces an > additional dependency -- all the routers within a site that has to > be renumbered have to be configured with both new and old addresses > *prior* to configuring DHCP servers within the site with new and > old addresses. > > You overstate the dependency: it is only necessary that all routers > for a prefix be configured with a prefix before the DHCP server > allocate addresses from that prefix. The dependency would not be needed as long as a BOOTP relay can be configured to stop using its old address and start using its new address for annotating DHCP messages. I hope this requirement would be quite reasonable for a BOOTP relay (although one could still argue that this requirement contradicts the original BOOTP spec). Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19862; 28 Sep 95 18:56 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19858; 28 Sep 95 18:56 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa23263; 28 Sep 95 18:56 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA01361; Thu, 28 Sep 1995 18:56:18 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA05739; Thu, 28 Sep 1995 18:55:41 -0400 Received: from hubbub.cisco.com by sol (5.x/SMI-SVR4) id AA16748; Thu, 28 Sep 1995 18:55:36 -0400 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id PAA02951 for host-conf@sol.eg.bucknell.edu; Thu, 28 Sep 1995 15:55:34 -0700 Message-Id: <199509282255.PAA02951@hubbub.cisco.com> To: host-conf@sol.eg.bucknell.edu Subject: DHCP options question Date: Thu, 28 Sep 95 15:55:33 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yakov Rekhter Folks, Could someone explain the rationale behind using IP addresses (rather than DNS names) for the following options: 1. LPR Server 2. NTP Server 3. NETBIOS over TCP/IP Name Server 4. NETBIOS over TCP/IP Datagram Distribution Server 5. X Window Font Server 6. X Window Display Manager 7. Mobile IP Home Agent Yakov. P.S. There are few other options that are expressed in terms of IP addresses, but perhaps could be expressed in terms of DNS names.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19944; 28 Sep 95 19:05 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19940; 28 Sep 95 19:05 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa23438; 28 Sep 95 19:05 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA03333; Thu, 28 Sep 1995 19:05:15 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA05818; Thu, 28 Sep 1995 19:04:56 -0400 Received: from greatdane.cisco.com by sol (5.x/SMI-SVR4) id AA16757; Thu, 28 Sep 1995 19:04:51 -0400 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id PAA09742; Thu, 28 Sep 1995 15:54:37 -0700 Date: Thu, 28 Sep 1995 15:54:37 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199509282254.PAA09742@greatdane.cisco.com> To: yakov@cisco.com Cc: host-conf@sol.eg.bucknell.edu In-Reply-To: <199509282237.PAA00858@hubbub.cisco.com> (message from Yakov Rekhter on Thu, 28 Sep 95 15:37:04 PDT) Subject: Re: renumbering with DHCP (moderately long) The dependency would not be needed as long as a BOOTP relay can be configured to stop using its old address and start using its new address for annotating DHCP messages. I hope this requirement would be quite reasonable for a BOOTP relay (although one could still argue that this requirement contradicts the original BOOTP spec). That's entirely reasonable and already deployed. ;-) Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07936; 29 Sep 95 8:31 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07932; 29 Sep 95 8:31 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa08617; 29 Sep 95 8:31 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA28002; Fri, 29 Sep 1995 08:29:16 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA07815; Fri, 29 Sep 1995 08:28:30 -0400 Received: from obelix.hrz.tu-chemnitz.de by sol (5.x/SMI-SVR4) id AA17179; Fri, 29 Sep 1995 08:28:18 -0400 Received: from sunnyboy.informatik.tu-chemnitz.de by obelix.hrz.tu-chemnitz.de with Local SMTP (PP) id <17508-0@obelix.hrz.tu-chemnitz.de>; Fri, 29 Sep 1995 13:27:46 +0100 Received: from zeta.informatik.tu-chemnitz.de by sunnyboy.informatik.tu-chemnitz.de (4.1/SMI-4.1) id AA17174; Fri, 29 Sep 95 13:28:36 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Anke Mann Received: by zeta.informatik.tu-chemnitz.de (4.1/client-1.5) id AA00181; Fri, 29 Sep 95 13:27:40 +0100 Message-Id: <9509291227.AA00181@zeta.informatik.tu-chemnitz.de> Subject: unsubsribe To: host-conf@sol.eg.bucknell.edu Date: Fri, 29 Sep 1995 13:27:32 +0100 (MET) Cc: Anke Mann X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please unsubscribe aman@informatik.tu-chemnitz.de   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08282; 29 Sep 95 9:08 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08278; 29 Sep 95 9:08 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa09338; 29 Sep 95 9:08 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA28221; Fri, 29 Sep 1995 09:10:32 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA07967; Fri, 29 Sep 1995 09:09:26 -0400 Received: from mailsender.syr.edu by sol (5.x/SMI-SVR4) id AA17292; Fri, 29 Sep 1995 09:09:19 -0400 Received: from gamera.syr.edu (jmwobus@gamera.syr.edu [128.230.1.14]) by mailsender.syr.edu (8.7/8.7) with SMTP id JAA07060 for ; Fri, 29 Sep 1995 09:20:43 -0400 (EDT) Received: by gamera.syr.edu (5.x/Spike-2.0) id AA09444; Fri, 29 Sep 1995 09:08:24 -0400 Message-Id: <9509291308.AA09444@gamera.syr.edu> Cc: host-conf@sol.eg.bucknell.edu Subject: renumbering & options questions In-Reply-To: Your message of "Thu, 28 Sep 1995 15:55:33 PDT." <199509282255.PAA02951@hubbub.cisco.com> Date: Fri, 29 Sep 1995 09:08:24 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "John M. Wobus" Yakov wrote: >Folks, > >Could someone explain the rationale behind using IP addresses (rather than >DNS names) for the following options: > >1. LPR Server >2. NTP Server >3. NETBIOS over TCP/IP Name Server >4. NETBIOS over TCP/IP Datagram Distribution Server >5. X Window Font Server >6. X Window Display Manager >7. Mobile IP Home Agent > >Yakov. > >P.S. There are few other options that are expressed in terms of IP >addresses, but perhaps could be expressed in terms of DNS names. Yakov has made me think. I'm don't know whether handing out names is a good thing on balance, but it occurs to me that one of the uses of BOOTP was to help net administrators change the parameters, sometimes of individual clients, sometimes on a large scale (renumbering clients, adding an XYZ server to the XYZ-server list, changing the IP number of the XYZ server, etc). In the BOOTP world, typically an administrator can change the parameters in the server, and know new parameters will get picked up when the client is rebooted. The administrator may know the client machines are booted daily, or might be able to announce to all that the machines should be rebooted, or might simply know people will reboot their machine if something isn't working. Ideally, DHCP would be designed to do as well as BOOTP or better. With 20/20 hindsight, it seems to me that whether it does or not depends upon implementations and/or on site policy which might be hobbled by implementation-specific details. A DHCP client with a long or permanent lease actually has permission to record the information on disk and not even look at the server again when the client is rebooted. It had occurred to me some time ago that there'd be some sense to making a "dual" (DHCP/BOOTP) client treat a BOOTP answer as a 24 hour lease rather than a permanent lease, so the client would check in daily for the type of changes I've been talking about. Would it make sense to have explicit features in DHCP to handle administration? Brainstorming, I'd say "how about a message that the server can send saying: 'just this once, get your parameters again'?" or "how about putting right in the standard that the clients should check in daily (or hourly, or at a site-settable interval) to see if there are administrative changes?". The latter can be done by offering only limited leases, but I'm not certain whether at the end of a lease, that the client is supposed to change all the parameters, or if it just refers to the leased IP number. In some sense, DHCP can't be faulted: BOOTP can do this stuff partly because of the BOOTP-clients implementation details, but there remains the issue of whether, on a practical level, that the new DHCP clients being propagated around the world are going to nullify the lucky situation we had before. Handing out names rather than numbers does give administrators a way of changing the IP numbers of some of the services if the client is written to store the name & resolve it each time rather than cheat, resolve the name once, and keep the number beyond the DNS-imposed timeout. -John Wobus   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08334; 29 Sep 95 9:12 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08330; 29 Sep 95 9:12 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa09507; 29 Sep 95 9:12 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA01046; Fri, 29 Sep 1995 09:14:20 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA07985; Fri, 29 Sep 1995 09:13:25 -0400 Received: from reef.bucknell.edu by sol (5.x/SMI-SVR4) id AA17302; Fri, 29 Sep 1995 09:13:19 -0400 Received: by reef.bucknell.edu (5.65/IDA-1.2.8) id AA01475; Fri, 29 Sep 1995 09:07:22 -0400 Date: Fri, 29 Sep 1995 09:07:22 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Message-Id: <9509291307.AA01475@reef.bucknell.edu> To: Anke.Mann@informatik.tu-chemnitz.de, host-conf@sol.eg.bucknell.edu Subject: Re: unsubsribe Cc: Andreas.Manthey@e-technik.tu-chemnitz.de I'm away from my office this week. I'll unsubscribe you from the DHCP mailing list as soon as I get back... - Ralph Droms   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10516; 29 Sep 95 11:32 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10512; 29 Sep 95 11:32 EDT Received: from [134.82.7.253] by CNRI.Reston.VA.US id aa12807; 29 Sep 95 11:32 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA24377; Fri, 29 Sep 1995 11:30:45 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA08917; Fri, 29 Sep 1995 11:29:52 -0400 Received: from hubbub.cisco.com by sol (5.x/SMI-SVR4) id AA17426; Fri, 29 Sep 1995 11:29:46 -0400 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id IAA04106 for host-conf@sol.eg.bucknell.edu; Fri, 29 Sep 1995 08:29:43 -0700 Message-Id: <199509291529.IAA04106@hubbub.cisco.com> To: host-conf@sol.eg.bucknell.edu Subject: host renumbering with DHCP Date: Fri, 29 Sep 95 08:29:42 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yakov Rekhter Folks, Based on the comments I got so far, I made few simplifications. Here is revised proposal. Please comment. Yakov. ----------------------------------cut here---------------------------- Site Hosts Renumbering with DHCP The following outlines how a site that uses DHCP could renumber its hosts. Implications on Routers (BOOTP relays) During renumbering each link (Data Link subnetwork) will be assigned multiple address prefixes (IP subnets) to cover both old and new addresses. Routers would need to be configured to (a) maintain routes to both old and new address prefixes, (b) maintain multiple addresses per interface (one address per IP subnet), and (c) should be able to distinguish between the old and the new prefixes for the purpose of annotating DHCPDISCOVER and DHCPREQUEST messages. When a router annotates a DHCPDISCOVER or DHCPREQUEST message, the router should annotate it (the 'giaddr' field) with an address that corresponds to a new address prefix. If there are more than one new address prefix, then the router should pick up an address that corresponds to a particular new prefix (as to provide consistent annotation). [ One could argue that the above represents a departure from RFC1542, which states that "If the interface has more than one IP address logically associated with it, the relay agent SHOULD choose one IP address associated with that interface and use it consistently for all BOOTP messages it relays." ] Implications on DHCP Servers In general a DHCP server maintains one or more blocks of addresses from which it can satisfy requests for new addresses. To facilitate renumbering it should be possible to mark some of these blocks (via configuration procedures) as 'deprecated' (we'll refer to such blocks and addresses out of such blocks as 'deprecated'). When a server receives a DHCPDISCOVER message from a client, the server handles the message following standard DHCP procedures, except for the case where 'giaddr' in the message is zero. In this case the server should always try to allocate an address out of a non-deprecated block, if possible. When a server receives a DHCPREQUEST message from a client, the server handles the message following standard DHCP procedure, except for the case where the the client is trying to extend its address lease and the address is from a deprecated block. In this case either (a) the server should refuse to extend the lease, or (b) the server is preconfigured with a certain "deadline" for extending the leases, and the server may extend the lease, but not beyond the deadline. [ One possible suggestion was to return a special (new) option, called "non-renewable", when a server doesn't expend the lease because the address is from a deprecated block. ] Operational considerations During renumbering it is expected that for some period of time the site would be able to use both the old and the new addresses. We refer to this time interval as an "overlap period". DHCP servers should be set in such a way that the value of the lease time and the Rebinding Time Value option returned by the servers would allow clients to change to the new addresses by the time the old ones become invalid. The overlap period should be longer than the lease time that the DHCP servers within the site are configured with. As the first step in the reconfiguration process, all the DHCP servers within a site should be configured with both old and new blocks of addresses. Once the servers are reconfigured, individual routers could be reconfigured (one at a time) to support routing to both old and new addresses. After none of the servers have any outstanding leases on old addresses, the old address blocks could be removed from the servers. At the same time, routers could be reconfigured to remove routes to old addresses.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11389; 29 Sep 95 12:36 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11384; 29 Sep 95 12:36 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa14047; 29 Sep 95 12:36 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA10720; Fri, 29 Sep 1995 12:28:45 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA09211; Fri, 29 Sep 1995 12:25:53 -0400 Received: from hubbub.cisco.com by sol (5.x/SMI-SVR4) id AA17479; Fri, 29 Sep 1995 12:25:47 -0400 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id JAA08447; Fri, 29 Sep 1995 09:25:11 -0700 Message-Id: <199509291625.JAA08447@hubbub.cisco.com> To: "John M. Wobus" Cc: host-conf@sol.eg.bucknell.edu Subject: Re: renumbering & options questions In-Reply-To: Your message of "Fri, 29 Sep 95 09:08:24 EDT." <9509291308.AA09444@gamera.syr.edu> Date: Fri, 29 Sep 95 09:25:10 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yakov Rekhter John, > Handing out names rather than numbers does give administrators a way of > changing the IP numbers of some of the services if the client is > written to store the name & resolve it each time rather than cheat, > resolve the name once, and keep the number beyond the DNS-imposed > timeout. That is correct, and that is why I questioned the rationale of using IP addresses, rather than DNS names. Yakov. P.S. Folks may consider looking at draft-iab-renum-01.txt, as this document discusses the issue of using IP addresses vs DNS names.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12291; 29 Sep 95 13:50 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12286; 29 Sep 95 13:50 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa15490; 29 Sep 95 13:50 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA05535; Fri, 29 Sep 1995 13:48:07 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA09798; Fri, 29 Sep 1995 13:47:21 -0400 Received: from henge1.henge.com by sol (5.x/SMI-SVR4) id AA17635; Fri, 29 Sep 1995 13:47:11 -0400 Received: from [204.144.151.162] ([204.144.151.162]) by henge1.henge.com (8.6.11/8.6.9) with SMTP id LAA23789 for ; Fri, 29 Sep 1995 11:49:51 -0600 Message-Id: <199509291749.LAA23789@henge1.henge.com> To: "host-conf@sol.eg.bucknell.edu" Subject: SUBSCRIBE DHCP Date: Fri, 29 Sep 95 11:48:32 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Michael Barnes X-Mailer: E-Mail Connection v2.5.03 -- [ From: Michael Barnes * EMC.Ver #2.5.02 ] -- SUBSCRIBE   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16780; 29 Sep 95 19:12 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16776; 29 Sep 95 19:12 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa21553; 29 Sep 95 19:12 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA15680; Fri, 29 Sep 1995 19:07:28 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA11301; Fri, 29 Sep 1995 16:15:20 -0400 Received: from uvite59.bucknell.edu by sol (5.x/SMI-SVR4) id AB17908; Fri, 29 Sep 1995 16:15:09 -0400 Date: Fri, 29 Sep 1995 16:15:09 -0400 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Re: DHCP options question Yakov Rekhter asked: >Could someone explain the rationale behind using IP addresses (rather than >DNS names) for the following options: The primary rationale for using IP addresses rather than DNS names is simplicity and length of data items. Using IP addresses helps keep the DHCP options list within a single UDP datagram. Also, the options you listed can also be considered "services" rather than IP stack configuration parameters; as such, they might better be passed to a TCP/IP host through a service location protocol. Finally, the DHCP server can, of course, keep the servers as DNS names and do the resolution on demand, returning the most current IP address for the service to the DHCP client. This solution is not, of course, as dynamic as passing the DNS name to the client. - Ralph   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05032; 30 Sep 95 0:14 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05028; 30 Sep 95 0:14 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa01528; 30 Sep 95 0:14 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA25404; Sat, 30 Sep 1995 00:12:41 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA12935; Sat, 30 Sep 1995 00:12:04 -0400 Received: from netcomsv.netcom.com (uucp7.netcom.com) by sol (5.x/SMI-SVR4) id AA18380; Sat, 30 Sep 1995 00:11:59 -0400 Received: from akhnaten.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id VAA13933; Fri, 29 Sep 1995 21:04:51 -0700 Received: from akhnaten.UUCP by join.com (4.1/SMI-4.1) id AA08852; Fri, 29 Sep 95 20:39:02 PDT Received: by join.com (4.1/SMI-4.1) id AA12030; Fri, 29 Sep 95 07:19:27 PDT Date: Fri, 29 Sep 95 07:19:27 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rob Stevens Message-Id: <9509291419.AA12030@join.com> To: glenroy!mailbox.syr.edu!jmwobus@netcom.com Subject: Re: renumbering & options questions Cc: host-conf@sol.eg.bucknell.edu > ... A DHCP client with a long or > permanent lease actually has permission to record the information on > disk and not even look at the server again when the client is > rebooted... That is not my understanding of DHCP. When the client reboots and finds a cached configuration it is nonetheless required to verify its address and parameters with the server. Only in the event that no server responds may it use them regardless. This is the so-called "init-reboot" state > > Would it make sense to have explicit features in DHCP to handle > administration? Brainstorming, I'd say "how about a message that the > server can send saying: 'just this once, get your parameters again'?" > or "how about putting right in the standard that the clients should > check in daily (or hourly, or at a site-settable interval) to see if > there are administrative changes?". The latter can be done by offering > only limited leases, but I'm not certain whether at the end of a lease, > that the client is supposed to change all the parameters, or if it just > refers to the leased IP number. Many clients would not be able to use a new-configuration without rebooting. > > In some sense, DHCP can't be faulted: BOOTP can do this stuff partly > because of the BOOTP-clients implementation details, but there remains > the issue of whether, on a practical level, that the new DHCP clients > being propagated around the world are going to nullify the lucky > situation we had before. I really don't understand why you say that bootp clients can do this. Bootp clients have infinite leases. If they don't reboot nothing changes. > > Handing out names rather than numbers does give administrators a way of > changing the IP numbers of some of the services if the client is > written to store the name & resolve it each time rather than cheat, > resolve the name once, and keep the number beyond the DNS-imposed > timeout This is inefficient both for client apps and for the protocol: to send a name will generally far more that the 6 bytes required to send an IP, so there is greater chance of not being able to fit all the info. in a single, non-fragmented, UDP datagram. Rob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10494; 30 Sep 95 21:37 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10490; 30 Sep 95 21:37 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa18869; 30 Sep 95 21:37 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA28253; Sat, 30 Sep 1995 21:37:17 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA15351; Sat, 30 Sep 1995 21:36:35 -0400 Received: from hubbub.cisco.com by sol (5.x/SMI-SVR4) id AA19132; Sat, 30 Sep 1995 21:36:27 -0400 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id SAA15137; Sat, 30 Sep 1995 18:36:21 -0700 Message-Id: <199510010136.SAA15137@hubbub.cisco.com> To: Ralph Droms Cc: host-conf@sol.eg.bucknell.edu Subject: Re: DHCP options question In-Reply-To: Your message of "Fri, 29 Sep 95 16:15:09 EDT." Date: Sat, 30 Sep 95 18:36:21 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yakov Rekhter Ralph, > Yakov Rekhter asked: > > >Could someone explain the rationale behind using IP addresses (rather than > >DNS names) for the following options: > > The primary rationale for using IP addresses rather than DNS names is > simplicity and length of data items. Using IP addresses helps keep the > DHCP options list within a single UDP datagram. I wonder whether use of DNS names (rather than IP addresses) would be a problem (wrt to single UDP datagram) in a common case. > Also, the options you > listed can also be considered "services" rather than IP stack configuration > parameters; as such, they might better be passed to a TCP/IP host through a > service location protocol. IMHO this is orthogonal to the issue of using DNS names vs IP addresses for the options that carry information about "services". > Finally, the DHCP server can, of course, keep > the servers as DNS names and do the resolution on demand, returning the > most current IP address for the service to the DHCP client. This solution > is not, of course, as dynamic as passing the DNS name to the client. I think this is still inadequate for the purpose of using DHCP for renumbering. Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10543; 30 Sep 95 21:42 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10539; 30 Sep 95 21:42 EDT Received: from coral.bucknell.edu by CNRI.Reston.VA.US id aa18955; 30 Sep 95 21:42 EDT Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA28850; Sat, 30 Sep 1995 21:43:11 -0400 Received: from sol by charcoal (5.x/SMI-SVR4) id AA15371; Sat, 30 Sep 1995 21:42:50 -0400 Received: from hubbub.cisco.com by sol (5.x/SMI-SVR4) id AA19139; Sat, 30 Sep 1995 21:42:44 -0400 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id SAA15249; Sat, 30 Sep 1995 18:42:35 -0700 Message-Id: <199510010142.SAA15249@hubbub.cisco.com> To: Rob Stevens Cc: host-conf@sol.eg.bucknell.edu Subject: Re: renumbering & options questions In-Reply-To: Your message of "Fri, 29 Sep 95 07:19:27 PDT." <9509291419.AA12030@join.com> Date: Sat, 30 Sep 95 18:42:35 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yakov Rekhter Rob, > This is inefficient both for client apps and for the protocol: > to send a name will generally far more that the 6 bytes required > to send an IP, so there is greater chance of not being able to > fit all the info. in a single, non-fragmented, UDP datagram. While I understand your point about the "greater chance", I wonder what is the likelyhood of this chance in a common case. Yakov.