From dhcp-v4@bucknell.edu Thu Apr 1 17:57:36 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05372 for ; Thu, 1 Apr 1999 17:57:35 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id RAA30030; Thu, 1 Apr 1999 17:50:14 -0500 (EST) Date: Thu, 1 Apr 1999 17:50:14 -0500 (EST) Message-Id: <63D30D6E10CFD11190A90000F805FE860110706D@lespaul.process.com> Errors-To: droms@bucknell.edu Reply-To: Gonczi@process.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Steve Gonczi To: Multiple recipients of list Subject: FW: DHCP LDAP Schema meeting minutes available X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.0.1460.8) Mime-Version: 1.0 Greetings, I have posted this message a while ago, but it did not seem to show up. Here it is (again). Minutes of the 1999 February 8-9 DHCP LDAP Schema Interim Meeting are available at the following URL: http://www.process.com/schemas/lastmeeting.htm Please post comments and suggestions to this list, (dhcp-v4@bucknell.edu) for the time being. kindest regards, Steve Gonczi From dhcp-v4@bucknell.edu Thu Apr 1 18:04:01 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05497 for ; Thu, 1 Apr 1999 18:04:00 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id SAA10093; Thu, 1 Apr 1999 18:01:13 -0500 (EST) Date: Thu, 1 Apr 1999 18:01:13 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: mike.henry@intel.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Henry, Mike" To: Multiple recipients of list Subject: FW: Draft minutes for Remote Boot BOF X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 > -----Original Message----- > From: Henry, Mike > Sent: Thursday, April 01, 1999 10:51 > To: 'dhcp-v4@bucknell.edu'; 'REMOTE_BOOT (E-mail)' > Subject: Draft minutes for Remote Boot BOF > > Below are the minutes for the remote boot BOF held Thursday 3/18. Please > send any corrections by Friday morning as they are due on Friday. I > apologize for the delay in getting the minutes out. I have not attached > the powerpoint presentation I used during the meeting (too large), but > they will be submitted with the minutes. > > Thanks, > > - Mike H. 3/31 > ---------------------- > > > Minutes of Remote Boot BOF > IETF 44 (Minneapolis, MN) > Thursday, March 18, 1999 > > Minutes reported by Mike Henry and Mike Carney. > > Agenda: > > 1. Introduction and agenda bashing Henry > 2. Intel's Agenda Henry > 3. Proposed Goals of WG Henry > 4. Overview of PXE Protocol Henry > 5. Use of SLP for bootserver discovery Guttman > 6. Discussion All > > > 2. Intel's Agenda > > o Establish portions of the PXE 2.0 specification as RFC standards > (http://developer.intel.com/ial/wfm/wfmspecs.htm) > * remote boot protocol > * remote boot mtftp for bootstrap download > * IANA registration for > - Booting Client types (Instruction Set Architecture) > - Bootserver types > > o Migrate proprietary methods within PXE to IP standards as the > standards become available > > o Provide path for remote boot support in Ipv6 > > > 3. Proposed Goals of WG > > Define a standard protocol between the remote boot client and the > responding server(s). > > The Working Group objective is to produce a protocol that insures > remote boot clients, of arbitrary platform and instruction set > architecture, will be able to choose an appropriate boot program > from an arbitrary variety of boot servers, without the necessity > of site-specific pre-configuration of the client. > > > 4. Overview of PXE Protocol > > Mike Henry gave an overview of the PXE remote boot protocol as defined > in the following two drafts: > > Remote Boot (draft-viswanathan-remote_boot-protocol-00.txt) > MTFTP (draft-viswanathan-remote_boot-mtftp-00.txt) > > [The slides for this presentation have been submitted with these > minutes.] > > Discussion followed: ("C." - comment, "Q." - Question, "A." - Answer) > > C. Security: something we need to address if we're a working group > (Narten) > > C. The NBP (Network Bootstrap Program) credential transaction is not > documented in the draft. > > C. We need to discuss the deficiencies of the current possibilities > (methods) (Narten) > > > Q. TFTP issue raised - some companies will not use tftp (security > concern??) > So, Appropriate for remote boot use?? > A. TFTP is current method for standard DHCP based boot roms. This is > not > new. > > Q. Concern about key distribution? > A. Only a public key is required for the platform; a private key is not > required. Further, the key is owned by the local IT organization. > > Q. MAC address is writable; are you aligned with IEEE802 body on this > issue? > A. No. Do we need to be? Not qualified to comment on viability of > dynamically writing MAC to guarantee its uniqueness, however, UUID > is > guaranteed to be unique. > C. Suggestion that we send a message to IEEE 802 body to announce our > issue > > C. Concern about use of unique identifiers (UUID as platform ID). Keep > that in mind > > Q. Are PXE strings ASCII? > A. (Not sure, check draft. [this was an internationalization > motivated question] > > Q. Is the server supposed to echo back "PXEClient" in Opt 60, > or the clients class "PXEClient:Arch:xxx:yyyy")? > A. Just "PXEClient" today.... > Q. Can you return the entire string? > A. Not clear, some DHCP servers do not appear to distinguish between > instances of Option 60. > > Q. Can the client send more identifying info (like kind of SCSI card, > etc.) > A. This is a Black hole - we decided to let the second level boot > program figure out additional HW config information. > > Q. What does "Intel Order" mean? > A. "little endian". > > > 5. Use of SLP for bootserver discovery > > Eric Guttman gave a short talk on how SLP could be used by the booting > to discover a suitable bootserver, even to the extent of accomplishing > this without use of a DHCP server. (This would be useful in a > "networking > in the small" environment.) > > You could use SLP to locate boot image (bootserver) - e.g. > - Platform =0 > - UNDI =3 > - - Credential = S2 > - - UUID --...... > > Works w/o DHCP > +-------------+ > | Boot Client | )) --> Attribute request > +-------------+ servicetype = remboot > ^ attr = platform, authen. Methods > | > | Attr Reply > | (platform = x86, sparc) > | +-------------+ > +----------------------------| Boot Server | > +-------------+ > > > Replace dhcp w/ slp for discovery of bootservers [actually, replace > proprietary PXE discovery protocol w/ slp] > > Q. Can you still encode policy / menu to clients with SLPv2? > A. Yes - selection among attributes > > Must be able to interdict preboot or postboot for administration > - SLPv2 can do this - Erik gave other example (Open Group) > > Q. How to set/determine priority of Boot Servers? > A. Could have a priority attribute to communicate to the client which > boot image from a group to select. > > > A document describing minimal use of SLP as discovery method for > Bootservers is needed to clarify how SLP would work and the extent > of change that would be necessary from current method. Eric > volunteered to write this up. > > 6. Next Steps - Areas Needing Work > > Areas Needing Work > 1. Security must be addressed in updated drafts > 2. The problem to be solved by a Remote Boot working group must be > defined by a requirements document that outlines remote boot > requirements and what requirements are currently not addressed. > In other words, what is inadequate about what is currently defined? > > Next Steps > 1. Write Requirements Document (Mike Henry, Mike Carney, > Marc Blanchet) > 2. Investigate current protocols. > 3. Decide what is warranted (choose): > a. a new standard > b. a BCP RFC document use of best use of current standards > c. no action; current standards are adequate > 4. Need a MIB > 5. Write SLP discovery doc. (Eric Guttman) > From dhcp-v4@bucknell.edu Fri Apr 2 14:19:26 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02066 for ; Fri, 2 Apr 1999 14:19:23 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id OAA32585; Fri, 2 Apr 1999 14:12:48 -0500 (EST) Date: Fri, 2 Apr 1999 14:12:48 -0500 (EST) Message-Id: <21839C593E75D211BF7800805FCCD0264B07AA@msgsrv03.srv.PacBell.COM> Errors-To: droms@bucknell.edu Reply-To: RBHIBBS@msg.pacbell.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "HIBBS, BARR (PB)" To: Multiple recipients of list Subject: RE: draft-ietf-dhc-dhcp-dns-09.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2232.9) Mime-Version: 1.0 Mark, Robert, et al., I realize I'm jumping into the middle of the conversation but I want to add my two cents' worth... my comments are inline... --Barr > ---------- > From: Mark Stapp[SMTP:mjs@cisco.com] > Sent: Friday, March 26, 1999 4:17 PM > To: Multiple recipients of list > Subject: Re: draft-ietf-dhc-dhcp-dns-09.txt > [ ... stuff deleted ... ] > >Most importantly (and then in decreasing order thereafter), I think, is > ... > > > > In addition, if the Client FQDN option carried in the DHCPREQUEST > > message has its Flags field set to 1, then the server MUST originate > > an update for the A RR (associated with the FQDN carried in the > > option). > > > [ ... ] > > The MUST in the > >quoted text needs to be (at a minimum) qualified, to indicate that this > need > >only be attempted if the the dhcp server has the necessary credentials > for > >the FQDN supplied. > --yes, I agree about the presumed delegation of authority that Robert raises, but how can this be determined a priori by the client and server? Presumably, if the DNS server has been configured to require credentials for add/update/delete of A records then somehow the necessary mechanism for distribution of credentials has been accomplished. If the administrators wish for clients to be able (or required) to delegate A record updates to the DHCP server, then the server will also have the necessary credentials. But how does the client know this to be the case? It seems to me that in order to avoid an administrative nightmare involving key management the client probably should not be able to selectively delegate A record updates to the server: I believe that either the client will always do so or never do so, not select who performs the update using this option. [Barr] > I'll try to make this clearer. The purpose of this flag is to allow the > client to indicate to the server that the client will _not_ perform an > update on the client's name. The draft certainly shouldn't imply that the > server should act in an arbitrary way in that case, especially if the > server knows that it cannot update a name like the one the client has > sent. > --I have always been uncomfortable with the notion that the client makes this determination. I firmly believe that it is an administrative choice, not a client choice. I think that in practice arbitrary behavior may not only be appropriate, but also the norm. To me, the choice of which party updates the A record is a policy issue, and I further assert that the whole idea that the client is authoritative for its FQDN may be faulty. In our case, we wish to be able to supply a client its FQDN through the option 12 (hostname) and option 15 (domain name) mechanism, choosing an identifier that conveys no particular information such as human's name, location, or function. Given that, by our policy choice, the client is told its name by the server, the server is authoritative for both the FQDN and the address, and we would never permit the client to "choose" to update the A record itself. I recognize that other organizations may have a different perspective, but I must insist that this I-D not preclude the appropriate administrative authority from establishing local policies that usurp the function proposed by this option. [Barr] [ ... stuff deleted ... ] > >Also, the encoding of the domain name > >field isn't stated. I'd strongly suggest encoding it using the same > method > >that is used in DNS packets (without name compression, of course), rather > >than attempting to encode it as a text string (which leads to all kinds > of > >complications). > > The fqdn option is a DHCP option, and it's currently an ASCII string like > the existing host-name and domain-name options. I'm inclined to leave it > that way unless there's clear agreement that it's insufficient. > --Mark, we are entering an era when the encoding of strings will become increasingly important. For robustness, I thing you should specify NVT ASCII here if that's what you mean. [Barr] > >Next most importantly, there seems to be no discussion about what should > be > >done in the event of a conflict - that is, where a dhcp server has been > >configured to supply a particular host name to the client, yet the client > >uses this new option to request a different fqdn. > > This is really an administrative matter. Sites may choose to allow their > servers to accept clients' suggestions, or rely on the servers' own > notions > of the names the clients should receive. I'll add words to that effect. > --unfortunately, this is a bigger problem: some well-known and widely-deployed clients do not accept server setting their hostname using option 12, and hence, are not able to specify FQDN. That doesn't mean that the server shouldn't be given the authority to specify the FQDN, or that a client must always accept the name... again, this is a local policy issue, and the draft should not force one behavior or another, but accept that a policy overrides the choice. [Barr] > >Then wrt ... > > > > If a server terminates a lease on an address prior to the lease > > expiration time, the server SHOULD ... > > > >Is there actually a DHCP way that can be done? [...] > > A server can reply to a client's request with a NAK, and the client will > give up its current lease and attempt to acquire a new one. If that > occurs, > the server should clean up the DNS. > > >Perhaps less serious ... > > > > If a client that owns/maintains is own FQDN wants to be responsible > > for updating the FQDN to IP address mapping for the FQDN and > > address(es) used by the client, then the client MUST include the > > Client FQDN option in the DHCPREQUEST message originated by the > > client. > > > >I would have thought that if a client wants to maintain its FQDN to IP > >mapping, and doesn't care about the address -> name mapping, then it > ought > >simply be able to update the A record itself, and there's no need to ever > >tell the DHCP server anything about it at all. [...] > > The sentence you've quoted appears immediately after this one: "The > following describes behavior of a DHCP client that implements the Client > FQDN option." Sites whose administrators don't care about this option can > use clients which don't implement it. Hopefully, the cooperation that the > draft describes is useful, and clients will implement it. > --while true, some firewalls require that specific mapping as a pre-condition for services such as FTP, WWW-browsing, and Telnet. In such a situation, allowing the client to update the A record without the server updating the PTR record would cause the client to suddenly "break," something that we should studiously avoid. [Barr] > >Next: > > > > If a client releases its address lease prior to the lease expiration > > time and the client is responsible for updating its A RR(s), the > > client SHOULD delete the A RR > > > >I'd like to see a justification for that SHOULD (rather than just MAY). > >In practice, clients rarely release leases anyway, they mostly just > switch > >off and go away, abandoning the lease (if it expires before they're ready > >to use it again). [...] > > Dangling names are seen as a very real administrative problem in many > organizations. There are popular clients which do release their leases, > and > their behavior needs to be accounted for in the draft. If a client accepts > responsibility for its name, it should make every effort not to leave the > name behind when it's no longer in use. > --true, but what about the more recalcitrant clients/users? Can we generically specify a means to surmount this problem? For example, can we tell DNS the lifetime of the resource records? (Robert, I defer to you about this...) Should we specify client behavior that does a reverse lookup before changing its name, deleting the old A record as a pre-condition for adding a new one? Or is there some mechanism by which the DNS server itself purges dangling names? [Barr] [ ... stuff deleted ... ] > >I would also like to see an example of a complete DHCP/DynDNS transation > >(or perhaps 2, to cover the two models) - from the initial DHCPDISCOVER > >until everything is completed, showing all of the relevant fields (ie: > >addresses and names, omitting other DHCP options that would normally be > >included as they're not rrelevant here). I think it would be also good > >to mention just what should be done when a lease is renewed - the doc as > it > >stands seems to really only cover the case where a lease is initially > being > >obtained (and also when it is released). > > > >In particular, I'd like this to tell me whether it is envisaged that > there > >is any interaction in this area between what the server sends in its > >DHCPOFFER, and how the client uses the FQDN option of the DHCPREQUEST. > > Do you mean that the text descriptions in 3.4.1 and 3.4.2 aren't complete, > or just that they aren't as clear as an example would be? > --I agree that a time-sequence diagram would be illustrative, although unless we are trying to completely specify so much of the implementations, perhaps it would be well-placed if it were in an appendix? [Barr] > >Then, a request - I think it is quite common for clients to know the > >least significant element of the domain name that they want to own, but > not > >to care much about what domain it is embedded into. That is, it would > be > >nice for the client to be able to supply just the hostname part, and have > >the server complete that by appending an appropriate domain name (and > return > >the complete thing to the client). [...] > > I agree. I'll make this clearer. > --yes, Robert makes a good point here: I agree. However, we have the small matter of options 12 and 15 to consider. I have always assumed that if one were to concatenate options 12 and 15 one would, in effect, be constructing the client's FQDN. If the use of this new option permits the server to take the client's suggested least significant part and append the remainder to construct an FQDN, then, if either by explicit request or local policy options 12 and or 15 are also returned to the client, then they MUST be aligned with the name returned by this option. [Barr] [ ... stuff deleted ... ] From dhcp-v4@bucknell.edu Fri Apr 2 15:36:04 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03276 for ; Fri, 2 Apr 1999 15:36:00 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id PAA12623; Fri, 2 Apr 1999 15:30:19 -0500 (EST) Date: Fri, 2 Apr 1999 15:30:19 -0500 (EST) Message-Id: <21839C593E75D211BF7800805FCCD0264B07AB@msgsrv03.srv.PacBell.COM> Errors-To: droms@bucknell.edu Reply-To: RBHIBBS@msg.pacbell.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "HIBBS, BARR (PB)" To: Multiple recipients of list Subject: RE: draft-ietf-dhc-dhcp-dns-09.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2232.9) Mime-Version: 1.0 > Mark, Robert, et al.-- > > again, I'm jumping into this a bit after the fact, and placing my comments > in-line... > > --Barr > > message sent to dhcp-v4@bucknell.edu by KRE@MUNNARI.OZ.AU follows. > ------------------------------------------------------------------ > Date: Fri, 26 Mar 1999 18:39:39 -0500 > From: Mark Stapp > Message-ID: <4.0.2.19990326182233.0116e2f0@funnel.cisco.com> > > | I'll try to make this clearer. The purpose of this flag is to allow > the > | client to indicate to the server that the client will _not_ perform an > | update on the client's name. > > OK, that makes more sense. I do think the text needs to be written more > with that slant in that case. > > | > It should probably actually say that it MUST NOT attempt > | >to update the A record in any other case. > > | I don't think that's correct: the client might not send anything, or > the > | server might be configured to perform the update (possibly because > only it > | has the necessary credentials) whether the client sets this flag or > not > | (see section 3, para. 3). > > All I meant was that the server should never do any updates unless it has > the necessary credentials. I would have thought that a self evident > restriction, though I may have phrased it badly. > > --I still assert that who updates what is a local administrative policy > decision, and not a client choice..., but, even in the case where clients > are granted the authority to update DNS there may be situations where a > client chooses to delegate its authority to update the A record to the > server, for that "transaction." This unfortunately raises another issue: > if the client delegates the A record update authority to the server, what > is the lifetime of that authority? Can the client subsequently update the > A record itself, or must it always somehow interact with the DHCP server? > If, once authority is granted to the server it remains for the lifetime of > the name-address binding, the client wishes to change its name, must it > send a new DHCPREQUEST message? If so, is it then permitted to request a > lease extension or other options? [Barr] > > | The fqdn option is a DHCP option, and it's currently an ASCII string > like > | the existing host-name and domain-name options. > > Is it? I didn't see where the draft says that. I'm also not sure > about the host-name option. It's been a while since I checked, but I > had the impression that the host name in that option was just a counted > sequence of bytes (since it has no defined internal structure there's no > need for anything more, and no rationale for it either). > > The domain name option I agree, that's a problem. > > | I'm inclined to leave it > | that way unless there's clear agreement that it's insufficient. > > By duplicating DNS format encoding you're guaranteeing that you can > represent any FQDN that the DNS can represent, which has to be sufficient. > As soon as you start altering the representation, difficulties can result > later. Eg: there is some demand for a better specification of domain > names > in international character sets, not just ascii (and also some > resistance). > What will happen there isn't clear yet (it is pretty clear that basically > nothing needs to be done to the basic DNS spec to achieve it though). > It would be a pity if it turns out that limitations on DHCP restrict names > more than the DNS will allow. One obvious example is that to use a pure > text form, some quoting scheme is needed to embed the "problem" characters > (like '.') when they form a part of a label, as distinct from being the > separator betwwwn labels. The DNS allows that, its packet format doesn't > even notice, and it has defined quoting methods to embed such things in > zone files. But a quoted name can be longer than 255 bytes (in its > quoted form), and would not fit in your fqdn option. In DNS binary > format > none of that can be an issue - whatever happens, the DNS binary packet > limits > are pretty much set in concrete required to maintain compatability. > > Unless there's a very good reason to use text formats (in which case the > actual text format to use needs to be precisely stated, don't just assume > it is "obvious", it isn't) using the DNS binary format in any protocol > which > is basically carrying binary encoded date (which DHCP certainly is) seems > like an obvious "right" choice to me (even if it does mean an extra few > lines > of code to deal with it). > > --the host name is very frequently assumed by client and server > implementations to be an ASCII string. While opening the range of > encodings for this option, option 12 and option 15 might be a very useful > change, that is perhaps more than we should do with this draft. I think > that we should simply specify the encoding (NVT ASCII, right?) and then, > separately, address the whole matter of how to encode names to match the > larger community. [Barr] > > | A server can reply to a client's request with a NAK, and the client > will > | give up its current lease and attempt to acquire a new one. If that > occurs, > | the server should clean up the DNS. > > Ah, I see what you mean, this occurs only when a client is attempting > to confirm (and usually extend) its lease. I think it would not hurt to > add something to make that clear, lest anyone be tempted to read the text > as implying that servers have some mechanism for arbitrarily terminating > client leases, without client co-operation. (It is a thing I > occasionally > see people asking how to do, since it is basically impossible to achieve, > avoiding anyone being given a "but see RFCnnnn where it says ..." type > argument). > > --okay, I think we agree that if the server NAKs the request, it should > update/delete the PTR record. But which party updates/deletes the A > record? Does the client's previous delegation of authority still apply > such that the server must do it, or may the client? If the client is > responsible for updating DNS and somehow doesn't manage, how is a dangling > lease prevented (or, at least, recognized and later resolved)? [Barr] > > | The sentence you've quoted appears immediately after this one: "The > | following describes behavior of a DHCP client that implements the > Client > | FQDN option." > > Sure, but "implements" and "desires to use" aren't the same thing. > > | Sites whose administrators don't care about this option can > | use clients which don't implement it. > > That is unreasonable. As you say ... > > | Hopefully, the cooperation that the > | draft describes is useful, and clients will implement it. > > Yes, hopefully clients will implement it. Hopefully all clients will > implement it. That doesn't mean that all sites will desire to use it. > And if all clients implement it, the "use a client which doesn't implememt > it" option for the site goes away... > > Avoid over specification - unless there is a very good operational reason > for a MUST, don't give one. The only reason I can see for requiring > the client to include the FQDN option is when it is requesting the server > to do something with the data. In that case, obviously the server needs > the value from the option to be able to function. If the server isn't > required to do anything with the fqdn, then there's no reason for the > client to supply the data - regardless of whether or not the clients > implementation supports it, and regardless of what dynamic dns > interactions > the client may intend to make. > > --last paragraph first: I agree with Robert about over-specification. > Now to the earlier points about clients and servers implementing this > option: in my case I know that our security people will never permit > clients to update DNS--they are even suspicious of a DHCP server doing > so.... So, this draft will only be acceptable to us if nothing in it > precludes our specifying a local administrative policy that prohibits > clients from updating DNS or precludes a DHCP server from always updating > both the A and PTR records. [Barr] > > | Dangling names are seen as a very real administrative problem in many > | organizations. > > Sure, and they're seen as no problem at all in others. > > | There are popular clients which do release their leases, and > | their behavior needs to be accounted for in the draft. > > Yes, I agree. > > | If a client accepts responsibility for its name, it should make every > | effort not to leave the name behind when it's no longer in use. > > That's a value judgement, in what should be something left to individual > sites to determine which they prefer. Some certainly prefer that stray > names be deleted when they're not in use. Others may prefer that the > names > be left as they were until they need to be updated to reflect the next > address > they obtain. Others may prefer that the A record be deleted, and > replaced > by a TXT record (or something) as a placeholder, so the name is retained, > but > the old A record isn't. This is all for local site determination, and > need not be specified by this draft. > > --Yes!! Local administrative policy should be the primary determinant of > this behavior. But I also believe that it is useful in the draft to > clarify both that it is a policy matter and how it might be accomplished. > [Barr] > > [ ... stuff deleted ... ] > > | Do you mean that the text descriptions in 3.4.1 and 3.4.2 aren't > complete, > | or just that they aren't as clear as an example would be? > > What started me wondering, was in attempting to determine whether the > server could provide any information which would assist the client in > sending the data for the fqdn option. There's the easy case where the > client has simply been configured, via some other means, with its desired > fqdn (which may happen for workstations, and similar things, which have a > user sitting in front of them). That is pretty straight forward. But > for > devices with no human around to configure the fqdn, but where the device > might just know enough of what it thinks it ought be called as a hostname > at least. But the domain name in which that name ought be installed > is likely to be unknown. The question is whether the server might supply > a domainname option in the dhcpoffer response to the dhcpdiscover, and > then the client construct its full name for the fqdn in the dhcprequest > packet from that domain name. Is that reasonable, simply wrong, ... > > --this option and its interaction (if any) with options 12 and 15 need > further exploration. [Barr] > > [ ... stuff deleted ... ] > From dhcp-v4@bucknell.edu Mon Apr 5 10:34:07 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06107 for ; Mon, 5 Apr 1999 10:34:06 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id KAA24210; Mon, 5 Apr 1999 10:27:55 -0400 (EDT) Date: Mon, 5 Apr 1999 10:27:55 -0400 (EDT) Message-Id: <199904051353.JAA08662@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: mjs@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mark Stapp To: Multiple recipients of list Subject: RE: draft-ietf-dhc-dhcp-dns-09.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Barr, Thanks very much for your comments. It sounds to me as if we're converging on a couple of points. First, the issue of domain-name encoding. I'm very concerned about breaking the population of existing MS clients which speak this option. I'd like to suggest that we use the third bit in the fqdn option's 'flags' field to indicate the nature of the encoding. A zero in that position will indicate that the fqdn is ASCII, a one will indicate that DNS encoding has been used. Clients should use dns encoding, and the server should reply with the encoding that the client has used. Second, you describe very clearly one of the administrative situations in which the DHCP server has a role that's central to the maintainance of DNS information. As you describe it, dhcp administrators do not want to give access to DNS to arbitrary clients, and do not want to oversee key distribution to every 'trusted' client. They'd even prefer not to distribute complete domain names to their DHCP clients manually, relying instead on DHCP replies to tell the clients about the domains they're in dynamically. The more centrally managed servers are the authoritative source for DNS updates, and may even be the authoritative source for clients' hostnames. Since the servers are 'on' all of the time, they are less likely to leave orphaned DNS names. That's a model that must be supported by the draft. Under the policy you describe, DHCP servers need to be able to tell clients that the servers will perform A and PTR updates, since the servers know that the clients do not have the appropriate credentials to do so. In addition, the DHCP servers need to be able to inform clients of the domain name that will be representing the client. I think both of those properties are in the current draft, in that the server can use the option's flags to indicate to the client that the server will perform both DNS updates. I will try to make the 'local policy' case clear, and I will make explicit the possibility that the server may return an fqdn option (and/or host-name+domain-name option pair) that is meant to tell a client what DNS name it has, rather than just echoing the client's choice. A few more comments inline: At 11:08 AM 4/2/99 -0800, HIBBS, BARR (PB) wrote: > >Mark, Robert, et al., > >I realize I'm jumping into the middle of the conversation but I want to add >my two cents' worth... > >my comments are inline... > >--Barr > > >> ---------- >> From: Mark Stapp[SMTP:mjs@cisco.com] >> Sent: Friday, March 26, 1999 4:17 PM >> To: Multiple recipients of list >> Subject: Re: draft-ietf-dhc-dhcp-dns-09.txt >> >[ ... stuff deleted ... ] > >> >Most importantly (and then in decreasing order thereafter), I think, is >> ... >> > >> > In addition, if the Client FQDN option carried in the DHCPREQUEST >> > message has its Flags field set to 1, then the server MUST originate >> > an update for the A RR (associated with the FQDN carried in the >> > option). >> > >> [ ... ] >> > The MUST in the >> >quoted text needs to be (at a minimum) qualified, to indicate that this >> need >> >only be attempted if the the dhcp server has the necessary credentials >> for >> >the FQDN supplied. >> >--yes, I agree about the presumed delegation of authority that Robert >raises, but how can this be determined a priori by the client and server? >Presumably, if the DNS server has been configured to require credentials for >add/update/delete of A records then somehow the necessary mechanism for >distribution of credentials has been accomplished. If the administrators >wish for clients to be able (or required) to delegate A record updates to >the DHCP server, then the server will also have the necessary credentials. >But how does the client know this to be the case? It seems to me that in >order to avoid an administrative nightmare involving key management the >client probably should not be able to selectively delegate A record updates >to the server: I believe that either the client will always do so or never >do so, not select who performs the update using this option. [Barr] > >> I'll try to make this clearer. The purpose of this flag is to allow the >> client to indicate to the server that the client will _not_ perform an >> update on the client's name. The draft certainly shouldn't imply that the >> server should act in an arbitrary way in that case, especially if the >> server knows that it cannot update a name like the one the client has >> sent. >> >--I have always been uncomfortable with the notion that the client makes >this determination. I firmly believe that it is an administrative choice, >not a client choice. I think that in practice arbitrary behavior may not >only be appropriate, but also the norm. To me, the choice of which party >updates the A record is a policy issue, and I further assert that the whole >idea that the client is authoritative for its FQDN may be faulty. In our >case, we wish to be able to supply a client its FQDN through the option 12 >(hostname) and option 15 (domain name) mechanism, choosing an identifier >that conveys no particular information such as human's name, location, or >function. Given that, by our policy choice, the client is told its name by >the server, the server is authoritative for both the FQDN and the address, >and we would never permit the client to "choose" to update the A record >itself. I recognize that other organizations may have a different >perspective, but I must insist that this I-D not preclude the appropriate >administrative authority from establishing local policies that usurp the >function proposed by this option. [Barr] > I used the word "arbitrary" in the sense of "unpredictable", to mean that the what the server will do should be controllable and defined. I agree that the DHCP server may be the authority for the DNS naming of DHCP clients, and that a client's DNS name may bear no resemblance to the 'host name' that a Win95 user configures into his or her own PC. >[ ... stuff deleted ... ] > >> >Also, the encoding of the domain name >> >field isn't stated. I'd strongly suggest encoding it using the same >> method >> >that is used in DNS packets (without name compression, of course), rather >> >than attempting to encode it as a text string (which leads to all kinds >> of >> >complications). >> >> The fqdn option is a DHCP option, and it's currently an ASCII string like >> the existing host-name and domain-name options. I'm inclined to leave it >> that way unless there's clear agreement that it's insufficient. >> >--Mark, we are entering an era when the encoding of strings will become >increasingly important. For robustness, I thing you should specify NVT >ASCII here if that's what you mean. [Barr] > Agreed. [ snip... ] > >> >Next: >> > >> > If a client releases its address lease prior to the lease expiration >> > time and the client is responsible for updating its A RR(s), the >> > client SHOULD delete the A RR >> > >> >I'd like to see a justification for that SHOULD (rather than just MAY). >> >In practice, clients rarely release leases anyway, they mostly just >> switch >> >off and go away, abandoning the lease (if it expires before they're ready >> >to use it again). [...] >> >> Dangling names are seen as a very real administrative problem in many >> organizations. There are popular clients which do release their leases, >> and >> their behavior needs to be accounted for in the draft. If a client accepts >> responsibility for its name, it should make every effort not to leave the >> name behind when it's no longer in use. >> >--true, but what about the more recalcitrant clients/users? Can we >generically specify a means to surmount this problem? For example, can we >tell DNS the lifetime of the resource records? (Robert, I defer to you about >this...) Should we specify client behavior that does a reverse lookup >before changing its name, deleting the old A record as a pre-condition for >adding a new one? Or is there some mechanism by which the DNS server itself >purges dangling names? [Barr] > There has been a proposal for 'expirable' DNS records, but I don't know how far it has gotten. There's an important trade-off here: if the records don't expire, the updaters don't have to refresh them as the clients' leases are extended, and that saves work and complexity. If clients are going to perform updates, and if we believe that clients may be shut down or moved frequently, then expirable records will be very useful. >[ ... stuff deleted ... ] > >> >I would also like to see an example of a complete DHCP/DynDNS transation >> >(or perhaps 2, to cover the two models) - from the initial DHCPDISCOVER >> >until everything is completed, showing all of the relevant fields (ie: >> >addresses and names, omitting other DHCP options that would normally be >> >included as they're not rrelevant here). I think it would be also good >> >to mention just what should be done when a lease is renewed - the doc as >> it >> >stands seems to really only cover the case where a lease is initially >> being >> >obtained (and also when it is released). >> > >> >In particular, I'd like this to tell me whether it is envisaged that >> there >> >is any interaction in this area between what the server sends in its >> >DHCPOFFER, and how the client uses the FQDN option of the DHCPREQUEST. >> >> Do you mean that the text descriptions in 3.4.1 and 3.4.2 aren't complete, >> or just that they aren't as clear as an example would be? >> >--I agree that a time-sequence diagram would be illustrative, although >unless we are trying to completely specify so much of the implementations, >perhaps it would be well-placed if it were in an appendix? [Barr] > Yes, I'll add an appendix to the next revision. >> >Then, a request - I think it is quite common for clients to know the >> >least significant element of the domain name that they want to own, but >> not >> >to care much about what domain it is embedded into. That is, it would >> be >> >nice for the client to be able to supply just the hostname part, and have >> >the server complete that by appending an appropriate domain name (and >> return >> >the complete thing to the client). [...] >> >> I agree. I'll make this clearer. >> >--yes, Robert makes a good point here: I agree. However, we have the small >matter of options 12 and 15 to consider. I have always assumed that if one >were to concatenate options 12 and 15 one would, in effect, be constructing >the client's FQDN. If the use of this new option permits the server to take >the client's suggested least significant part and append the remainder to >construct an FQDN, then, if either by explicit request or local policy >options 12 and or 15 are also returned to the client, then they MUST be >aligned with the name returned by this option. [Barr] > This is reasonable, but I'm a little concerned about the encoding issue. If the fqdn option uses DNS encoding, the fqdn data may need to be re-encoded mapped to fit into the existing host-name and domain-name options. Mark From dhcp-v4@bucknell.edu Mon Apr 5 14:47:08 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13250 for ; Mon, 5 Apr 1999 14:47:02 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id NAA18434; Mon, 5 Apr 1999 13:50:07 -0400 (EDT) Date: Mon, 5 Apr 1999 13:50:07 -0400 (EDT) Message-Id: <21839C593E75D211BF7800805FCCD0264B07AE@msgsrv03.srv.PacBell.COM> Errors-To: droms@bucknell.edu Reply-To: RBHIBBS@msg.pacbell.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "HIBBS, BARR (PB)" To: Multiple recipients of list Subject: RE: draft-ietf-dhc-dhcp-dns-09.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2232.9) Mime-Version: 1.0 Mark-- first of all, Thank You Very Much! for taking the lead in advancing this draft.... some of us have been Waiting a Very Long Time.... Instead of interspersing all of my comments in the previous strings of messages, I'll summarize them here, and then add some context if the point requires it.... On the issue of encoding names: we briefly touched on this in Orlando, only getting so far as to agree that it was an issue we needed to resolve in general for all of the DHCP options. Robert raises the very good point that any name [and I think, any fragment of a name, such as option 12] that can be/is used with DNS probably ought to be encoded such that it is directly usable. Having said that, I also believe that we must solve the general problem, which we cannot do in a single Internet-Draft for one specific option. I am neutral about using a flag to be interpreted as "DNS encoding" because I haven't thought through how many cases we might be likely to be required to cover. Regarding local administrative policies as to which party (DHCP client or server) ought to update the A records, I only want to ensure that the draft does not preclude an administrator from saying, "In our case, clients will never be permitted to directly update DNS: only the servers will." It seems to me that if such a policy were in force, the DHCP server would not need to explicitly tell a client of this policy, but merely operate transparently to the client. If the client in such a case were to include the FQDN option in a request message, the server could still respond as if it had acted on behalf of the client to update the A record. Would it be appropriate for the draft to specify appropriate client behavior if the server asserts its authority? In this case, I believe the client should just quietly accept that the server did so, rather than declining or releasing the address lease, or starting the discover cycle again. Still, this comes down to a question of how to coordinate the dialogue between the two parties. Also, consider the case where the server is an early adopter of DNS dynamic updating, but the clients lag several weeks or months behind. It may not be a good idea for the server to return this option to the client, filled-in with appropriate status info, to a client which did not include the option directly or in its parameter request list, even if that means the client is then ignorant of DNS update activity occurring on its behalf. --Barr > ---------- > From: Mark Stapp[SMTP:mjs@cisco.com] > Sent: Monday, April 05, 1999 7:30 AM > To: Multiple recipients of list > Subject: RE: draft-ietf-dhc-dhcp-dns-09.txt > [ ... stuff deleted ... ] > Second, you describe very clearly one of the administrative situations in > which the DHCP server has a role that's central to the maintainance of DNS > information. As you describe it, dhcp administrators do not want to give > access to DNS to arbitrary clients, and do not want to oversee key > distribution to every 'trusted' client. They'd even prefer not to > distribute complete domain names to their DHCP clients manually, relying > instead on DHCP replies to tell the clients about the domains they're in > dynamically. The more centrally managed servers are the authoritative > source for DNS updates, and may even be the authoritative source for > clients' hostnames. Since the servers are 'on' all of the time, they are > less likely to leave orphaned DNS names. That's a model that must be > supported by the draft. > > Under the policy you describe, DHCP servers need to be able to tell > clients > that the servers will perform A and PTR updates, since the servers know > that the clients do not have the appropriate credentials to do so. > --As I said above, it may be a better choice for the server to simply do so without informing the client, unless the client includes the option in it's request message. [Barr] > In addition, the DHCP servers need to be able to inform clients of the > domain > name that will be representing the client. > --If I may interpret, you are suggesting that in such a case the server SHOULD or MUST return the FQDN as registered. Okay, but what if the server, by local policy decision, just updates DNS without the client requesting? Should the server then (1) return the FQDN option completed as seems to be appropriate, or (2) return BOTH options 12 and 15 to the client. There is a third possibility: the client might include the FQDN option in their parameter request list but not as a separate option. I think we agree that informing the client as to actions taken on their behalf may be a very good idea, but should we do so if the client didn't request the appropriate option(s) for the information? In my own implementation, there is one specific case where I stuff option 12 into messages to the client even if they did not request it or include it in their request of the server, so I'm comfortable with the server doing so in another situation. But is that always the right thing to do? [Barr] > I think both of those properties are in the current draft, in that the > server can use the option's flags to indicate to the client that the > server will perform both DNS updates. I will try to make the 'local > policy' case clear, and I will make explicit the possibility that the > server may return an fqdn option (and/or > host-name+domain-name option pair) that is meant to tell a client what DNS > name it has, rather than just echoing the client's choice. > > A few more comments inline: > > At 11:08 AM 4/2/99 -0800, HIBBS, BARR (PB) wrote: > [ ... stuff deleted ... ] > >> From: Mark Stapp[SMTP:mjs@cisco.com] > >> Sent: Friday, March 26, 1999 4:17 PM > >> To: Multiple recipients of list > >> Subject: Re: draft-ietf-dhc-dhcp-dns-09.txt > [ ... stuff deleted ... ] >--true, but what about the more recalcitrant clients/users? Can we > >generically specify a means to surmount this problem? For example, can > we > >tell DNS the lifetime of the resource records? (Robert, I defer to you > about > >this...) Should we specify client behavior that does a reverse lookup > >before changing its name, deleting the old A record as a pre-condition > for > >adding a new one? Or is there some mechanism by which the DNS server >itself purges dangling names? [Barr] > There has been a proposal for 'expirable' DNS records, but I don't know > how > far it has gotten. There's an important trade-off here: if the records > don't expire, the updaters don't have to refresh them as the clients' > leases are extended, and that saves work and complexity. If clients are > going to perform updates, and if we believe that clients may be shut down > or moved frequently, then expirable records will be very useful. > --this is a matter that needs more thought, and probably the concurrence of the DNS folk... [Barr] [ ... stuff deleted ... ] From dhcp-v4@bucknell.edu Mon Apr 5 21:05:38 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18065 for ; Mon, 5 Apr 1999 21:05:36 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id UAA02310; Mon, 5 Apr 1999 20:58:39 -0400 (EDT) Date: Mon, 5 Apr 1999 20:58:39 -0400 (EDT) Message-Id: <199904060054.UAA05536@bcn.East.Sun.COM> Errors-To: droms@bucknell.edu Reply-To: Radia.Perlman@East.Sun.COM Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Radia Perlman - Boston Center for Networking To: Multiple recipients of list Subject: Naive philosophy question: What distinguishes DHCP from BOOTP? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii Mime-Version: 1.0 To me, DHCP looks just like another version of BOOTP. I originally thought DHCP was when the "vendor specific" field got redefined as a true "options" field with registered options values. But then someone pointed out the RFC that defined the use of the vendor specific field for BOOTP, which came out several years after BOOTP. So my original theory (that you can tell it's DHCP because of the magic cookie) is wrong, since BOOTP used the same cookie value. I know DHCP does dynamic leasing of addresses and BOOTP doesn't. But it's backward compatible with BOOTP. So how would you answer when a naive person asks "what's the difference between DCHP and BOOTP? How can you tell when a packet is DHCP vs BOOTP? Is it just if it contains options not defined early enough (before BOOTP got renamed DHCP?) Or is it really a meaningless question, and there's no reason to be able to tell whether a packet is one or the other? Thanks, Radia From dhcp-v4@bucknell.edu Tue Apr 6 11:58:46 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12011 for ; Tue, 6 Apr 1999 11:58:46 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id LAA23339; Tue, 6 Apr 1999 11:49:22 -0400 (EDT) Date: Tue, 6 Apr 1999 11:49:22 -0400 (EDT) Message-Id: <199904061316.JAA23321@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: Naive philosophy question: What distinguishes DHCP from X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Radia, The pragmatic answer to the question "How can you tell when a packet is DHCP vs BOOTP?" is that a packet is DHCP if and only if it contains a dhcp-message-type option (option code 53). This option defines the packet not only as a DHCP packet, but also determines which type of DHCP packet it is. Many (most?) DHCP servers today also support one or more varieties of BOOTP, and they determine that an input packet is a BOOTP packet by the absence of the dhcp-message-type option. Cheers -- Kim At 09:00 PM 4/5/99 -0400, Radia Perlman - Boston Center for Networking wrote: >To me, DHCP looks just like another version of BOOTP. I originally >thought DHCP was when the "vendor specific" field got redefined >as a true "options" field with registered options values. >But then someone pointed out the RFC that defined the use of >the vendor specific field for BOOTP, which came out several years >after BOOTP. So my original theory (that you can tell it's DHCP >because of the magic cookie) is wrong, since BOOTP used the same cookie value. > >I know DHCP does dynamic leasing of addresses and BOOTP doesn't. > >But it's backward compatible with BOOTP. > >So how would you answer when a naive person asks "what's the difference >between DCHP and BOOTP? > >How can you tell when a packet is DHCP vs BOOTP? Is it just if it contains >options not defined early enough (before BOOTP got renamed DHCP?) Or >is it really a meaningless question, and there's no reason to be able >to tell whether a packet is one or the other? > >Thanks, > >Radia > From dhcp-v4@bucknell.edu Tue Apr 6 15:54:58 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16117 for ; Tue, 6 Apr 1999 15:54:57 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id PAA32743; Tue, 6 Apr 1999 15:27:10 -0400 (EDT) Date: Tue, 6 Apr 1999 15:27:10 -0400 (EDT) Message-Id: <3.0.6.32.19990406105349.00909310@ix.netcom.com> Errors-To: droms@bucknell.edu Reply-To: johnmtdm@ix.netcom.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "John J. Marbury" To: Multiple recipients of list Subject: help X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) help From dhcp-v4@bucknell.edu Tue Apr 6 18:32:36 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19374 for ; Tue, 6 Apr 1999 18:32:34 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id SAA04697; Tue, 6 Apr 1999 18:25:11 -0400 (EDT) Date: Tue, 6 Apr 1999 18:25:11 -0400 (EDT) Message-Id: <4.0.2.19990405095507.01a72eb0@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: mjs@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mark Stapp To: Multiple recipients of list Subject: Re: comments on dhcp-dns-09 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Edward, Thanks very much for your comments. I will forward your message to the dhcp list along with this reply, if that's all right. I've cc'd all of your ccs in case they're interested but not subscribed to the dhcp list. My reply's inline: At 03:21 PM 3/30/99 -0500, Edward Lewis wrote: >Here are some comments I have on the draft. Other members of TIS Labs may >add or refine these comments, so they are CC'd. If the authors wish to >forward these onto the DHCP mailing list, you may do so. I am not on the >list. > >Protocol related: > >If you add a two byte field for a DNS RR type, this structure can be made >more general. Not that this field would be used right away - fixing the >value at 1 for now (the DNS type value for A) is fine. > >Adding this would enable experimentation into including other types (such >as HINFO). I recommend not pursuing that right now, but allowing for it >would be a good idea. > Would you like to see a general-purpose option that clients would use to tell servers which DNS records they'd like added to their names? I can imagine that it would be useful for a server to offer the capability of adding various kinds of DNS records as clients get leases, but that feels like a server implementation feature, not a client feature. It sounds as if you'd like to allow a DHCP client to be able to specify the kind and contents of DNS records that a DHCP server would add on its behalf. I'm loathe to resist generality, but that's a stretch from the existing draft. The current option proposal doesn't specify a way to convey the RRDATA that the client would like added, for example. Using your HINFO example, a client would have to be able to describe itself, and the server would have to know how to represent that description in the HINFO RRDATA. Would the 'flags' and 'rrcode' fields in the FQDN option be meaningful in the HINFO example? I'm not sure that we want to specify that any server which can add A and PTR records can also add any arbitrary resource record type. Is there an application that you have in mind where this would be useful? Are there others out there who'd like to see this capability? If so, does that capability have to be part of this draft, or should it be a separate draft on the more general problem? I see the existing issues as more limited, and the existing draft is an attempt to address them. >The last line of section 3.1 - the FQDN should be represented in the DNS >protocol format (as opposed to the printed version). > Yes, several others have noticed this issue as well. There is a large population of shipped clients (from MS) which have begun using this option already, and which use an ASCII format. I'll propose offering the DNS encoding as an option, and allocating one of the 'flags' bits to indicate that that encoding is being used. >Behavior related: > >o - Securing the update of a name's A (address) record is difficult for the >server. In the case where the dhcp server and the authortative zone are >under one network administrative staff, it is conceivable that the dhcp >server could hold a DNSSEC zone private key for signing the records. > >However, if the authoritative server and the dhcp server are not of the >same organization (thus no sharing of a private key), then the server would >have to send unsigned data. In this case, a transaction signature is >necessary, but that is something configured between a DNS server and a >client (which would bt the DHCP server). Even if this configuration is >made to be automatic, e.g., an exchange like Diffie-Hellman, the DNS server >may not be willing to accept updates from a remote DHCP server. > There is a significant interest in the dhcp community in supporting sites which only allow dynamic updates from their DHCP servers. That reflects several concerns, including the costs of per-client configuration and key distribution, and the possibility that clients will be moved or deactivated and will be unable to update or remove DNS records which they added. These sites are generally large organizations where all updates are directed at that organization's own DNS servers. Credentials for DNS updates to the internal DNS servers only have to be distributed to the organization's DHCP servers in that model. The concerns of those sites may change over time, particularly if DNSSEC becomes more generally deployed, and the current draft supports several administrative models. >o - There is a proposal in the DNSIND WG to add something called "deferred >delete" which may be able to handle the removal of records when a lease >expires. This means that a DHCP server could issue a data update and a >data removal in the same DNS message. > I have the draft (it's draft-ietf-dnsind-dddd-00.txt, for those dhcp list members who haven't seen it), and it sounds great. This will certainly be useful (if supported by DNS servers) if clients are performing updates. It would mean, of course, that updaters would have to 'refresh' the delayed-delete ttl when they renew leases. That additional work might well be seen as worthwhile at sites which are concerned about orphaned or incorrect records. >o - A "Name collision" is an unfamiliar term to me. If you are concerned >that multiple dhcp clients will want the same domain name, this is not a >problem for DNS. It is relatively common to have a domain name have A >records for many addresses, with these addresses being on different >machines. This is done, for example, to load balance across numerous web >servers. (Perhaps a farm of WWW servers could be using DHCP to get their >addresses.) > >There is also the possibility that you are concerned about RR set >collisions. There may be other data already in existence at a name, such >as a public key, and no address set. In this case, there is a "name >collision" (as in the name is already in DNS) but no other host is using >the name. > What I think I meant (though I may not have said it clearly) is pretty specific: if two clients _think_ they should be using the same domain name, and if they both try to update DNS to associate their IP addresses with that name (or ask DHCP servers to associate them with the name), they conflict. That's not the same case as an administrator's intentionally configuring round-robining for his or her web servers. In many DHCP installations, having several DHCP clients attached to a single domain name would be considered an administrative error. It's also common for large DHCP sites to have several DHCP servers, all serving hosts in a few DNS zones. If a DHCP client moves from one subnet to another, it may move from one DHCP server to another: the second DHCP server needs to have a way to distinguish this situation. The draft describes a way to detect collisions and distinguish between hosts who have moved and new hosts whose names collide with existing DNS names. >o - The KEY RR is now defined in RFC 2535 (see section 3.4, near its end in >your document). The RFC mentioned in the draft has been obsoleted by 2535. > Thanks: I'll update this. >o - IMHO, after thinking over my comments & thoughts (some of which are >just on the paper copy), a DHCP server should not attempt to enter data >into DNS on behalf of the client - with two exceptions. One is the PTR >record that needs to be updated as a result of the lease. (The "reverse >map" is a domain name pertaining to an address. See my final paragragh.) >The other is the situation in which the DHCP server has a private DNS zone >key and acts as a surrogate DNS zone signer for its updates. > >A client that wants to use a certain domain name's information will likely >be pre-configured with keys, corresponding to public keys in the DNS at >than name. Because of this, the client will be in a better situation for >securing its updates. > The kind of client you're describing is supported by the 09 draft. That client can set the flags in the fqdn option appropriately, the client's network administrator can configure the DHCP server to allow the client to perform its own A update, and the administrator can configure the client and the zone's DNS server with appropriate credentials. There are many clients, however, who cannot perform their own updates, or which are on networks whose administrators have a policy which only allows updates from the DHCP servers. That configuration is also supported. In addition, a client which is allowed to perform its own updates can, by following the protocol in the draft, cooperate with other DNS updaters. >There is an important distinction between host name and (fully qualified) >domain name. A domain name is just a locator into the DNS data base, so >what is stored at a given name may pertain to one host name, a group of >(load sharing) hosts, an address (PTR record), or a non-host item like an >email address. This is perhaps the basis of my comments above. > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis Network Associates/TIS >Phone: +1 443-259-2352 Email: lewis@tislabs.com > >Think globally, scope locally. >"Trying is the first step to failure." - Homer Simpson >"No! Try not. Do... or do not. There is no try." - Yoda > >Opinions expressed are property of my evil twin, not my employer. > -- Mark From dhcp-v4@bucknell.edu Tue Apr 6 23:07:24 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23258 for ; Tue, 6 Apr 1999 23:07:20 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id XAA18478; Tue, 6 Apr 1999 23:00:31 -0400 (EDT) Date: Tue, 6 Apr 1999 23:00:31 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Minutes from Minneapolis WG meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Included below are the minutes from the afternoon (DHCPv4) meeting of the DHC WG. Please review and reply with comments by noon, Thursday (4/8) so I can submit the minutes Thursday afternoon (the minutes are due 4/7 (sic)). - Ralph ===== Thanks to Kim Kinnear for compiling these minutes. DHCP-DNS -- Mark Stapp (Cisco) ============================ Mark will submit a new draft that will include a new section 3.4 for handling name collisions: o DHCP servers and clients should be able to detect and resolve host name collisions. o Use a "KEY" RR to associate client with a DNS name. o Method describes use of "KEY" RR in prerequisites. Open issues: Is this an adequate solution? Is use of KEY RR correct? Olafur Gudmundsson (TIS) suggested that we might need to define some unique protocol id when we get to using public keys in the KEY record. Mark pointed out that Stuart Kwan (Microsoft) has suggested putting some sort of ACL information in the record as well, but that Mark hasn't moved forward on that. DHCP Authentication Status -- Bill Arbaugh (University of Pennsylvania) ======================================================================== Bill discussed open issues with the current draft: 1. Over specified key usage. Will be taken care of by changing SHOULD's to MUST's. 2. PKI Usage. Olafur volunteered to give some examples. He will do so. Examples demonstrating the use of shared secret HMAC are already in the draft. Kerberos could use this too according to Ted Lemon (ISC). 3. Securing relay agent interaction. This will be easy to fix by examining a few fields and will be addressed in the next draft. 4. Global replay protection. Adequate protection can be obtained by moving some fields up to the front of the packet and will be addressed in the next draft. 5. Client-id -- how to identify the client. This is a more difficult problem. Mike Henry's (Intel) UUID (option 61) could solve the problem if made mandatory in DISCOVER's when requesting authentication. GUID (Leach/Salz draft) has expired, but there is an open group standard that Mike referenced. 6. Kiosk Problem The "kiosk problem" arises when a previously unregistered computer tries to use DHCP authentication in a network where it doesn't know what key to use. Solving the kiosk problem is not practical without changes to the protocol state machine. The WG concluded that the kiosk problem is not easy to solve at the interim authentication meeting in Redmond last year. Trying to do this without livelock or deadlock is hard. The kisok problem is solvable outside of the protocol if there is a truly unique global UID, because client can register out of band ahead of time. Another possibility would be to leverage EAP if we changed the protocol to send ACK/NAK after DISCOVERs (for instance). If solving the kiosk problem requires changes to the DHCP protocol, then the problem won't be solved soon. WG came to consensus not to support a solution to the kiosk problem and not to change the DHCP protocol. 7. EAP (authentication used in PPP). (See above for reference to EAP authentication) New issues in DHCP Authentication: * Mark Stapp asked "What about RELEASE, INFORM, etc? These messages don't seem to be mentioned in the draft". Bill said that he would add text to specify authenticated RELEASE and INFORM in the next draft. * Someone asked "What is the basic idea behind the "key-id""? Bill answered that this was put in before some other part of the protocol was designed. There may not be a 1-1 mapping from keys to clients. This allows multiple clients to share keys -- which some people think is a bad thing, but the real answer is that it is useful sometimes and not useful sometimes. The secret-id field is type dependent, and exists only for the hmac today. When a client sends a request, the client gets back a key-id from the server, and then the client knows what key to send to the server. Bill said that he would clarify that in the next draft. Bill said that he would update the draft in the next month, send it to the list, and allow the list to respond. Bill doesn't see any further outstanding issues. The draft will go to WG last call after Bill completes the next revision of the draft. DHCP Schema Meeting Report -- Bernie Volz (Process Software) ============================================================ Bernie listed the attendees. Andy Bennett will update the draft and send it out to the attendee list. A couple of issues: 1. Is this the right group to develop a DHCP schema? The people at the schema meeting felt that keeping this in the DHC WG group was a good idea. Bernie Volz and Ralph Droms (Bucknell University) will talk offline about how to extend the DHC group charter to include the DHCP schema. 2. Andrea from Microsoft helped bring the CIM model and the network working group inside of the DMTF into perspective for the DHCP Schema task force. 3. There was significant discussion about whether or not to store leases in the schema. WG expressed consensus to do so, because they are sometimes used for other tools. Decision was to allow but not require this update, and certainly not to require it to be used as an authoritative store. The group working on the DHCP LDAP schema has made good progress; there is lots of work left to do. DHCP Failover Meeting Report -- Kim Kinnear (Cisco) =================================================== There was an interim meeting on the failover protocol February 10th and 11, 1999. The minutes from the meeting were distributed on the dhcp-serve@bucknell.edu mailing list and are available at http://www.dhcp.org. There will be a new draft published to accommodate the changes resulting from the interim meeting work. Summary of changes discussed at interim meeting: * Load balancing based on hash of link-layer addresses * TCP to be used for data transmission, UDP for polling * Time synchronization to be suggested but not required; poll messages will transmit current time to allow determination of drift * A straw-person security mechanism based on a shared secret, message digests and sequence numbers. Suggestions: 1. Try for dynamic load balancing. 2. Bernie Volz asked "What about when we have TCP and UDP w/different transmission speeds -- and we send state in the messages.". Kim Kinnear responded that we should just not put state in the TCP messages. 3. Servers should not assume that clients only send INIT-REBOOTs when they have time remaining on their lease. The DHCP RFC must be edited to clarify that a client MUST NOT send an INIT-REBOOT to a server unless it believes that it has time left to run on its lease for the IP address. Ralph Droms (Bucknell University) noted as an aside that the DHCP RFC 2131 could go to the next step of the standards process anytime someone volunteered to edit in the considerable number of changes that Ralph has collected since the last publication. Subnet Selection Option Status -- Glenn Waters (Nortel) ======================================================= This option allows the for a DHCP proxy service, especially in cases where the DHCP server cannot route at all to a network for which it is supplying IP addresses. Mark Stapp asked why not do an option to change to whom to send the packet and use giaddr to select the subnet. This entirely equivalent to the proposed option, but might generalize differently. Kim Kinnear pointed out that giaddr is used for two different things today, to select the subnet and to decide to whom to send the reply packet. Glenn's approach is to use a separate option to override the subnet selection aspect of the giaddr, but leave the "to whom to send the reply" part of it the same. One could, as Mark suggests, use an option to alter the "to whom to send the reply" part of the giaddr instead. The concensus of the group was to leave it way it was. Glenn said that he would update the draft to make it not "subnet specific" but network segment specific. Relay Agent Options Report from IESG -- Harald Alvestrand ========================================================= IESG sent the relay agent options draft back to the working group. Harald spoke to the WG to discuss the objections that came up at IESG. Having read the scenario at the beginning of the relay agent options draft, Harald has some global concerns with the scenario described (not with the specifics of the relay agent options themselves). His two primary concerns are: 1. What happens if a bunch of devices in, say, a house get addresses from a DHCP server across the network, and then the network goes down? What happens to the devices in the house that would like to talk to each other over the still, intact, network that is running inside the house? 2. What about when a DHCP client sends a DISCOVER and that is broadcast, and the kid-next-door gets the broadcast and responds with an bogus address? Harald will accept the relay-agent-options draft if it discusses the above problems that can occur when using the scenario outlined in the draft. Hopefully the draft will do more than warn people about these problems, and will also suggest some solutions. He would be satisfied with two sentences, but really would prefer two paragraphs. Kim suggested that there are solutions to at least some of these problems in the DOCSIS documents. Kim Kinnear volunteered to inform Mike Patrick of Motorola about these issues and let him know what he needs to do to move the draft forward. DHCP Options For Host System Characteristics -- Mike Henry (Intel) ================================================================== The DHCP Options for Host System Characteristcis draft , draft-dittert-host-sys-char-03.txt, has been revised. Options 93, 94 and 97 will be replaced with options 60 and 61, with a six year grace period for the transition. The document will go to WG last call and publication as an informational RFC. Connectathon Report -- Mike Carney ================================== Lots of people went. Two issues came up around the draft: 1. How is parameter request list used? Must it be the same each time? Mike is suggesting that it not be required, and that servers move more and more into sending only what clients ask for. 2. Issues around asking for very long addresses. Some clients always ask for a permanent address just to see if they can get one, and expect the server to limit them. This caused problems for some server limitations, and Mike noted that people may want to test this sometimes. Mike suggested ways to convince vendors to participate in connectathon, since the more servers and clients that participate the better the whole event works for all concerned. He suggested that Ralph put up some information (like who attended) on the dhcp.org web site. He also suggested that we might try to get some cable modem clients to connectathon next year. From dhcp-v4@bucknell.edu Wed Apr 7 07:26:14 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03835 for ; Wed, 7 Apr 1999 07:26:13 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id HAA28500; Wed, 7 Apr 1999 07:12:23 -0400 (EDT) Date: Wed, 7 Apr 1999 07:12:23 -0400 (EDT) Message-Id: <199904071044.GAA18822@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: Secondary nameservers X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 message sent to dhcp-v4@bucknell.edu by SDEAN@POP.ULSTER.NET follows. --------------------------------------------------------------------- I'm sure you've already thought of this, but if you haven't, it would be nice if the standard would include fields for secondary and tertiary nameservers.....our campus provides them, but there doesn't appear to be any way to include them in our server. Of course, this may already be in the standard, and our AIX DHCP server implementation doesn't include them. Wonder if the Windows client does, if it would take them if they were served. We have backup nameservers, but can't dish them out. When the primary nameserver goes down or is unreachable, DHCP clients suffer.... Enlighten my ignorance... // "I build my cars to go, not to stop", Ettore Bugatti // Stewart Dean Kingston, NY From dhcp-v4@bucknell.edu Wed Apr 7 08:52:50 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07251 for ; Wed, 7 Apr 1999 08:52:48 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id IAA18396; Wed, 7 Apr 1999 08:45:26 -0400 (EDT) Date: Wed, 7 Apr 1999 08:45:26 -0400 (EDT) Message-Id: <199904071241.IAA09231@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: mjs@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mark Stapp To: Multiple recipients of list Subject: Re: Secondary nameservers X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Stewart, The 'domain name servers' DHCP option is defined to be a list of ips, sorted in preference order. Windows clients >= win95 will use the list (at least the first two servers in the list) in order, in the way that you'd expect. It sounds as if the limitation is in your server's ui: there are a number of options that are defined to be an array of something, so it would be a bit surprising if the server itself can't deal with them. I'm not familiar with that server, so I can't suggest a workaround. If you post another message, or a follow-up to this message, with a more exact description of the server - what vendor, revision, etc. - you might locate someone who knows how to get your server to do what you want it to do. Mark At 07:15 AM 4/7/99 -0400, dhcp-v4@bucknell.edu wrote: > >message sent to dhcp-v4@bucknell.edu by SDEAN@POP.ULSTER.NET follows. >--------------------------------------------------------------------- >standards, but has a comment> > >I'm sure you've already thought of this, but if you haven't, it >would be nice if the standard would include fields for secondary and >tertiary nameservers.....our campus provides them, but there doesn't >appear to be any way to include them in our server. >Of course, this may already be in the standard, and our AIX DHCP >server implementation doesn't include them. Wonder if the Windows >client does, if it would take them if they were served. > >We have backup nameservers, but can't dish them out. When the >primary nameserver goes down or is unreachable, DHCP clients >suffer.... > >Enlighten my ignorance... >// "I build my cars to go, not to stop", Ettore Bugatti >// Stewart Dean Kingston, NY > From dhcp-v4@bucknell.edu Wed Apr 7 14:55:28 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13528 for ; Wed, 7 Apr 1999 14:55:25 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id OAA01482; Wed, 7 Apr 1999 14:45:57 -0400 (EDT) Date: Wed, 7 Apr 1999 14:45:57 -0400 (EDT) Message-Id: <4.0.2.19990406174916.01a64b90@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: mjs@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mark Stapp To: Multiple recipients of list Subject: Re: draft-ietf-dhc-dhcp-dns-09.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Robert, Thanks again for your comments. I've made a few replies/assents/mea culpas inline. I've done some snipping, so please feel free to correct me if I over-did it. At 09:55 PM 3/27/99 +1100, Robert Elz wrote: [snip] > > | The fqdn option is a DHCP option, and it's currently an ASCII string like > | the existing host-name and domain-name options. > [snip] > >Unless there's a very good reason to use text formats (in which case the >actual text format to use needs to be precisely stated, don't just assume >it is "obvious", it isn't) using the DNS binary format in any protocol which >is basically carrying binary encoded date (which DHCP certainly is) seems >like an obvious "right" choice to me (even if it does mean an extra few lines >of code to deal with it). > Yes, this was clearly a shortcoming, and there's consensus that I need to allow for this encoding. I've proposed (in a reply that went to the dhcp list, and that you probably didn't see) using the next bit in the 'flags' field as an indicator that the fqdn is DNS-encoded. In that case, would it be reasonable to allow a host to send a single element or label as an indication that it knows only the most-specific part of its domain name, and would like the DHCP server to append the rest? > | A server can reply to a client's request with a NAK, and the client will > | give up its current lease and attempt to acquire a new one. If that >occurs, > | the server should clean up the DNS. > >Ah, I see what you mean, this occurs only when a client is attempting >to confirm (and usually extend) its lease. I think it would not hurt to >add something to make that clear, lest anyone be tempted to read the text >as implying that servers have some mechanism for arbitrarily terminating >client leases, without client co-operation. (It is a thing I occasionally >see people asking how to do, since it is basically impossible to achieve, >avoiding anyone being given a "but see RFCnnnn where it says ..." type >argument). > Will do. > > | The sentence you've quoted appears immediately after this one: "The > | following describes behavior of a DHCP client that implements the Client > | FQDN option." > >Sure, but "implements" and "desires to use" aren't the same thing. > > | Sites whose administrators don't care about this option can > | use clients which don't implement it. > >That is unreasonable. As you say ... > > | Hopefully, the cooperation that the > | draft describes is useful, and clients will implement it. > >Yes, hopefully clients will implement it. Hopefully all clients will >implement it. That doesn't mean that all sites will desire to use it. >And if all clients implement it, the "use a client which doesn't implememt >it" option for the site goes away... > >Avoid over specification - unless there is a very good operational reason >for a MUST, don't give one. The only reason I can see for requiring >the client to include the FQDN option is when it is requesting the server >to do something with the data. In that case, obviously the server needs >the value from the option to be able to function. If the server isn't >required to do anything with the fqdn, then there's no reason for the >client to supply the data - regardless of whether or not the clients >implementation supports it, and regardless of what dynamic dns interactions >the client may intend to make. > Since the server is going to perform the PTR update, and the PTR update needs to know the name that the client is going to try to add, the client MUST tell the server what it thinks its name is. The draft could require that the client send the existing host-name option instead, but that doesn't offer the opportunities for the server to reply with additional information like that carried by the fqdn option's 'flags' and 'rcode' fields. In addition, I can envision a configuration in which the DHCP servers are configured to perform updates for clients unless the clients ask to perform the updates themselves. In organizations with a mixture of update-capable and -incapable clients, or during a period of transition after the general release of updating clients, it would save DHCP and DNS servers work if the DHCP clients advertised their intentions. The other operational case that motivates this is that of sites which intend to prohibit updates from DHCP clients. In those sites, servers need to be able to 'override' the client's offer to perform the A record update, as described in the draft's section 3.1, last para. Given those three cases, can the specification remain a MUST, or should it be a SHOULD? > | Dangling names are seen as a very real administrative problem in many > | organizations. > >Sure, and they're seen as no problem at all in others. > > | There are popular clients which do release their leases, and > | their behavior needs to be accounted for in the draft. > >Yes, I agree. > > | If a client accepts responsibility for its name, it should make every > | effort not to leave the name behind when it's no longer in use. > >That's a value judgement, in what should be something left to individual >sites to determine which they prefer. Some certainly prefer that stray >names be deleted when they're not in use. Others may prefer that the names >be left as they were until they need to be updated to reflect the next address >they obtain. Others may prefer that the A record be deleted, and replaced >by a TXT record (or something) as a placeholder, so the name is retained, but >the old A record isn't. This is all for local site determination, and >need not be specified by this draft. > The 'clean up after yourself' specification is a SHOULD, not a MUST. If this becomes a MAY, can I at least add a sentence to the effect that vendors are encouraged to clean up thoroughly? [snip] > > | Do you mean that the text descriptions in 3.4.1 and 3.4.2 aren't complete, > | or just that they aren't as clear as an example would be? > >What started me wondering, was in attempting to determine whether the >server could provide any information which would assist the client in >sending the data for the fqdn option. There's the easy case where the >client has simply been configured, via some other means, with its desired >fqdn (which may happen for workstations, and similar things, which have a >user sitting in front of them). That is pretty straight forward. But for >devices with no human around to configure the fqdn, but where the device >might just know enough of what it thinks it ought be called as a hostname >at least. But the domain name in which that name ought be installed >is likely to be unknown. The question is whether the server might supply >a domainname option in the dhcpoffer response to the dhcpdiscover, and >then the client construct its full name for the fqdn in the dhcprequest >packet from that domain name. Is that reasonable, simply wrong, ... > Ah, I think I understand the issue better now. Section 3.3, para. 5 says that the server MUST reply with a copy of the data the client sent. I'll revise that to try to allow for the case where the server has more knowledge about the more-general parts of the DNS domain that the client is in. The server may need to tell the client everything, in fact: one DHCP administrative policy may be to configure client's fqdns at the DHCP server, and avoid per-client configuration. In that case the server may need to be able to communicate all of the host-name info to the client. Mark From dhcp-v4@bucknell.edu Thu Apr 8 14:14:33 1999 Received: from marge.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05144 for ; Thu, 8 Apr 1999 14:14:27 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by marge.bucknell.edu (8.9.3/8.9.2) with SMTP id OAA30114; Thu, 8 Apr 1999 14:06:35 -0400 (EDT) Date: Thu, 8 Apr 1999 14:06:35 -0400 (EDT) Message-Id: <199904081505.LAA19571@prospero.dma.isg.mot.com> Errors-To: droms@bucknell.edu Reply-To: mpatrick@dma.isg.mot.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Michael W. Patrick" To: Multiple recipients of list Subject: DHCP Relay Agent Options -06 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: exmh version 1.6.7 5/3/96 Harald, I'm attaching what I'd like to submit as rev -06 of the agent options draft, with only slight rewording of the two paragraphs we've been discussing privately. Harald, is my revised wording of the paragraphs OK with you? Any other major objections? Both paragraphs are explanatory in nature, and do not have spec wording. Here are the two new paragraphs: In 1.1: Note that using this method to obtain IP addresses means that IP addresses can only be obtained while communication to the central site is available. Some host lan installations may use a local DHCP server or other methods to obtain IP addresses for in-house use. In 5.0: While it is beyond the scope of this document to specify the general forwarding algorithm of public data circuit access units, note that automatic reforwarding of IP or ARP broadcast packets back downstream exposes serious IP security risks. For example, if an upstream broadcast DHCP-DISCOVER or DHCP-REQUEST were re-broadcast back downstream, any public host may easily spoof the desired DHCP server. Regards, -mike DHC Working Grop Michael Patrick Motorola ING April 8, 1999 DHCP Relay Agent Information Option Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. Abstract Newer high-speed public Internet access technologies call for a high-speed modem to have a LAN attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol as defined in RFC 2131 [1] to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such "public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132 [2]. The new option is called the Relay Agent Information option and is inserted by the DHCP relay agent when forwarding client-originated DHCP packets to a DHCP server. Servers recognizing the Relay Agent Information option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to Expires October 1999 [Page 1] April 8, 1999 the client. The "Relay Agent Information" option is organized as a single DHCP option that contains one or more "sub-options" that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a "circuit ID" for the incoming circuit, a "remote ID" which provides a trusted identifier for the remote high-speed modem, and the "subnet mask" of the logical IP subnet from which the relay agent received the client DHCP packet. Table of Contents 1 Introduction........................................... 3 1.1 High-Speed Circuit Switched Data Networks.............. 3 1.2 DHCP Relay Agent in the Circuit Access Equipment....... 5 2.0 Relay Agent Information Option......................... 6 2.1 Agent Operation........................................ 7 2.1.1 Reforwarded DHCP requests............................ 8 2.2 Server Operation....................................... 8 3.0 Relay Agent Information Suboptions..................... 9 3.1 Agent Circuit ID....................................... 9 3.2 Agent Remote ID........................................ 10 3.3 Agent Subnet Mask...................................... 11 4.0 Issues Resolved........................................ 11 5.0 Security Considerations................................ 12 6.0 IANA Considerations.................................... 13 7.0 References............................................. 13 8.0 Glossary............................................... 13 9.0 Author's Address....................................... 14 Revision History Rev Date Description --- -------- ----------- -06 4/8/99 Added editorial paragraph at end of 1.1 noting that some host lan installations may not rely on a centralized DHCP server. Added editorial pararaph at end of 5.0 noting the security risks of automatically reforward- ing IP/ARP packets back downstream. Expires October 1999 [Page 2] April 8, 1999 1 Introduction 1.1 High-Speed Circuit Switched Data Networks Public Access to the Internet is usually via a circuit switched data network. Today, this is primarily implemented with dial-up modems connecting to a Remote Access Server. But higher speed circuit access networks also include ISDN, ATM, Frame Relay, and Cable Data Networks. All of these networks can be characterized as a "star" topology where multiple users connect to a "circuit access unit" via switched or permanent circuits. With dial-up modems, only a single host PC attempts to connect to the central point. The PPP protocol is widely used to assign IP addresses to be used by the single host PC. The newer high-speed circuit technologies, however, frequently provide a LAN interface (especially Ethernet) to one or more host PCs. It is desirable to support centralized assignment of the IP addresses of host computers connecting on such circuits via DHCP. The DHCP server can be, but usually is not, co-implemented with the centralized circuit concentration access device. The DHCP server is often connected as a separate server on the "Central LAN" to which the central access device (or devices) attach. A common physical model for high-speed Internet circuit access is shown in Figure 1, below. Expires October 1999 [Page 3] April 8, 1999 +---------------+ | Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host A LAN | | Access | Lan |- Host B | | Unit 1 | |- Host C |-----| |-- | | |(relay agent) |... +---------+ | +---------------+ | DHCP |--| | Server | | +---------+ | | | +---------------+ +---------+ | | Circuit |-- ckt 1--- Modem2-- Host--- Host D | Other | | | Access | Lan | Servers |--|-----| Unit 2 | | (Web, | | | |-- ckt 2--- Modem3-- Host--- Host E | DNS) | | |(relay agent) |... Lan | | +---------------+ +---------+ Figure 1: DHCP High Speed Circuit Access Model Note that in this model, the "modem" connects to a LAN at the user site, rather than to a single host. Multiple hosts are implemented at this site. Although it is certainly possible to implement a full IP router at the user site, this requires a relatively expensive piece of equipment (compared to typical modem costs). Furthermore, a router requires an IP address not only for every host, but for the router itself. Finally, a user-side router requires a dedicated Logical IP Subnet (LIS) for each user. While this model is appropriate for relatively small corporate networking environments, it is not appropriate for large, public accessed networks. In this scenario, it is advantageous to implement an IP networking model that does not allocate an IP address for the modem (or other networking equipment device at the user site), and especially not an entire LIS for the user side LAN. Note that using this method to obtain IP addresses means that IP addresses can only be obtained while communication to the central site is available. Some host lan installations may use a local DHCP server or other methods to obtain IP addresses for in-house use. Expires October 1999 [Page 4] April 8, 1999 1.2 DHCP Relay Agent in the Circuit Access Unit It is desirable to use DHCP to assign the IP addresses for public high-speed circuit access. A number of circuit access units (e.g. RAS's, cable modem termination systems, ADSL access units, etc) connect to a LAN (or local internet) to which is attached a DHCP server. For scaling and security reasons, it is advantageous to implement a "router hop" at the circuit access unit, much like high-capacity RAS's do today. The circuit access equipment acts as both a router to the circuits and as the DHCP relay agent. The advantages of co-locating the DHCP relay agent with the circuit access equipment are: DHCP broadcast replies can be routed to only the proper circuit, avoiding, say, the replication of the DCHP reply broadcast onto thousands of access circuits; The same mechanism used to identify the remote connection of the circuit (e.g. a user ID requested by a Remote Access Server acting as the circuit access equipment) may be used as a host identifier by DHCP, and used for parameter assignment. This includes centralized assignment of IP addresses to hosts. This provides a secure remote ID from a trusted source -- the relay agent. A number of issues arise when forwarding DHCP requests from hosts connecting publicly accessed high-speed circuits with LAN connections at the host. Many of these are security issues arising from DHCP client requests from untrusted sources. How does the relay agent know to which circuit to forward replies? How does the system prevent DHCP IP exhaustion attacks? This is when an attacker requests all available IP addresses from a DHCP server by sending requests with fabricated client MAC addresses. How can an IP address or LIS be permanently assigned to a particular user or modem? How does one prevent "spoofing" of client identifer fields used to assign IP addresses? How does one prevent denial of service by "spoofing" other client's MAC addresses? All of these issues may be addressed by having the circuit access equipment, which is a trusted component, add information to DHCP client requests that it forwards to the DHCP server. Expires October 1999 [Page 5] April 8, 1999 2.0 Relay Agent Information Option This document defines a new DHCP Option called the Relay Agent Information Option. It is a "container" option for specific agent- supplied sub-options. The format of the Relay Agent Information option is: Code Len Agent Information Field +------+------+------+------+------+------+--...-+------+ | 82 | N | i1 | i2 | i3 | i4 | | iN | +------+------+------+------+------+------+--...-+------+ The length N gives the total number of octets in the Agent Information Field. The Agent Information field consists of a sequence of SubOpt/Length/Value tuples for each sub-option, encoded in the following manner: SubOpt Len Sub-option Value +------+------+------+------+------+------+--...-+------+ | 1 | N | s1 | s2 | s3 | s4 | | sN | +------+------+------+------+------+------+--...-+------+ SubOpt Len Sub-option Value +------+------+------+------+------+------+--...-+------+ | 2 | N | i1 | i2 | i3 | i4 | | iN | +------+------+------+------+------+------+--...-+------+ No "pad" sub-option is defined, and the Information field shall NOT be terminated with a 255 sub-option. The length N of the DHCP Agent Information Option shall include all bytes of the sub-option code/length/value tuples. Since at least one sub-option must be defined, the minimum Relay Agent Information length is two (2). The length N of the sub-options shall be the number of octets in only that sub-option's value field. A sub-option length may be zero. The sub-options need not appear in sub-option code order. The initial assignment of DHCP Relay Agent Sub-options is as follows: DHCP Agent Sub-Option Descrption Sub-option Code --------------- ---------------------- 1 Agent Circuit ID Sub-option 2 Agent Remote ID Sub-option 3 Agent Subnet Mask Sub-option Expires October 1999 [Page 6] April 8, 1999 New sub-option codes MUST be assigned by IANA according to the policy described in the "IANA Considerations" section of this document. 2.1 Agent Operation Overall adding of the DHCP relay agent option SHOULD be configurable, and SHOULD be disabled by default. Relay agents SHOULD have separate configurables for each sub-option to control whether it is added to client-to-server packets. A DHCP relay agent adding a Relay Agent Information field SHALL add it as the last DHCP agent option in the DHCP options field of any recognized DHCP packet forwarded from a client to a server. Such additions shall be made for only those packets recognized as DHCP; BOOTP-only packets shall not be affected. Relay agents receiving a DHCP packet with giaddr set to zero (indicating that they are the first-hop router) but with a Relay Agent Information option already present in the packet SHALL discard the packet and increment an error count. Relay agents MAY have a configurable for the maximum size of the DHCP packet to be created after appending the Agent Information option. Packets which, after appending the Relay Agent Information option, would exceed this configured maximum size shall be forwarded WITHOUT adding the Agent Information option. An error counter SHOULD be incremented in this case. In the absence of this configurable, the agent SHALL NOT increase a forwarded DHCP packet size to exceed the MTU of the interface on which it is forwarded. The Relay Agent Information option echoed by a server MUST be removed by the agent when forwarding a server-to-client response back to the client. The agent SHALL NOT add an "Option Overload" option to the packet or use the "file" or "sname" fields for adding Relay Agent Information option. It SHALL NOT parse or remove Relay Agent Information options that may appear in the sname or file fields of a server-to-client packet forwarded through the agent. The operation of relay agents for specific sub-options is specified with that sub-option. Relay agents are NOT required to monitor or modify client-originated DHCP packets addressed to a server unicast address. This includes the DHCP-REQUEST sent when entering the RENEWING state. Expires October 1999 [Page 7] April 8, 1999 2.1.1 Reforwarded DHCP requests A DHCP relay agent may receive a client DHCP packet forwarded from a BOOTP/DHCP relay agent closer to the client. Such a packet will have giaddr as non-zero, and may or may not already have a DHCP Relay Agent option in it. Relay agents configured to add a Relay Agent option which receive a client DHCP packet with a nonzero giaddr SHALL discard the packet if the giaddr spoofs a giaddr address implemented by the local agent itself. Otherwise, the relay agent SHALL forward any received DHCP packet with a valid non-zero giaddr WITHOUT adding any relay agent options. Per RFC 2131, it shall also NOT modify the giaddr value. 2.2 Server Operation DHCP servers unaware of the Relay Agent Information option will ignore the option upon receive and will not echo it back on responses. This is the specified server behavior for unknown options. DHCP servers claiming to support the Relay Agent Information option SHALL echo the entire contents of the Relay Agent Information option in all replies. Servers SHOULD copy the Relay Agent Information option as the last DHCP option in the response. Servers SHALL NOT place the echoed Relay Agent Information option in the overloaded sname or file fields. If a server is unable to copy a full Relay Agent Information field into a response, it SHALL send the response without the Relay Information Field, and SHOULD increment an error counter for the situation. The operation of DHCP servers for specific sub-options is specified with that sub-option. Note that DHCP relay agents are not required to monitor unicast DHCP messages sent directly between the client and server (i.e, those that aren't sent via a relay agent). However, some relay agents MAY chose to do such monitoring and add relay agent options. Consequently, servers SHOULD be prepared to handle relay agent options in unicast messages, but MUST NOT expect them to always be there. Expires October 1999 [Page 8] April 8, 1999 3.0 Relay Agent Information Sub-options 3.1 Agent Circuit ID Sub-option This sub-option MAY be added by DHCP relay agents which terminate switched or permanent circuits. It encodes an agent-local identifier of the circuit from which a DHCP client-to-server packet was received. It is intended for use by agents in relaying DHCP responses back to the proper circuit. Possible uses of this field include - Router interface number - Switching Hub port number - Remote Access Server port number - Frame Relay DLCI - ATM virtual circuit number - Cable Data virtual circuit number Servers MAY use the Circuit ID for IP and other parameter assignment policies. The Circuit ID SHOULD be considered an opaque value, with policies based on exact string match only; that is, the Circuit ID SHOULD NOT be internally parsed by the server. The DHCP server SHOULD report the Agent Circuit ID value of current leases in statistical reports (including its MIB) and in logs. Since the Circuit ID is local only to a particular relay agent, a circuit ID should be qualified with the giaddr value that identifies the relay agent. SubOpt Len Circuit ID +------+------+------+------+------+------+------+------+-- | 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ... +------+------+------+------+------+------+------+------+-- Expires October 1999 [Page 9] April 8, 1999 3.2 Agent Remote ID Sub-option This sub-option MAY be added by DHCP relay agents which terminate switched or permanent circuits and have mechanisms to identify the remote host end of the circuit. The Remote ID field may be used to encode, for instance: -- a "caller ID" telephone number for dial-up connection -- a "user name" prompted for by a Remote Access Server -- a remote caller ATM address -- a "modem ID" of a cable data modem -- the remote IP address of a point-to-point link -- a remote X.25 address for X.25 connections The remote ID MUST be globally unique. DHCP servers MAY use this option to select parameters specific to particular users, hosts, or subscriber modems. The option SHOULD be considered an opaque value, with policies based on exact string match only; that is, the option SHOULD NOT be internally parsed by the server. The relay agent MAY use this field in addition to or instead of the Agent Circuit ID field to select the circuit on which to forward the DHCP reply (e.g. Offer, Ack, or Nak). DHCP servers SHOULD report this value in any reports or MIBs associated with a particular client. SubOpt Len Agent Remote ID +------+------+------+------+------+------+------+------+-- | 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ... +------+------+------+------+------+------+------+------+-- Expires October 1999 [Page 10] April 8, 1999 3.3 Agent Subnet Mask Sub-option This sub-option MAY be added by DHCP relay agents to identify the subnet mask of the Logical IP Subnet (LIS) from which the client DHCP packet was received. The LIS of the client is defined as the subnet formed by the giaddr ANDed with the Agent Subnet Mask. Servers MAY use this mask field to automatically create scopes of assignable IP addresses. Use of this field avoids the need to have identical configuration of the logical IP subnets on which clients reside in both the relaying routers and the DHCP server. In this case, the router configuration defines the LISs, and the DHCP servers automatically discover the LISs from the relay agent options of forwarded client DHCP requests. SubOpt Len Agent Subnet Mask +------+------+------+------+------+------+ | 3 | 4 | m1 | m2 | m3 | m4 | +------+------+------+------+------+------+ 4.0 Issues Resolved Broadcast Forwarding The circuit access equipment forwards the normally broadcasted DHCP response only on the circuit indicated in the Agent Circuit ID. DHCP Address Exhaustion In general, the DHCP server may be extended to maintain a database with the "triplet" of (client IP address, client MAC address, client remote ID) The DHCP server SHOULD implement policies that restrict the number of IP addresses to be assigned to a single remote ID. Expires October 1999 [Page 11] April 8, 1999 Static Assignment The DHCP server may use the remote ID to select the IP address to be assigned. It may permit static assignment of IP addresses to particular remote IDs, and disallow an address request from an unauthorized remote ID. IP Spoofing The circuit access device may associate the IP address assigned by a DHCP server in a forwarded DHCP Ack packet with the circuit to which it was forwarded. The circuit access device MAY prevent forwarding of IP packets with source IP addresses -other than- those it has associated with the receiving circuit. This prevents simple IP spoofing attacks on the Central LAN, and IP spoofing of other hosts. Client Identifer Spoofing By using the agent-supplied Agent Remote ID option, the untrusted and as-yet unstandardized client identifer field need not be used by the DHCP server. MAC Address Spoofing By associating a MAC address with an Agent Remote ID, the DHCP server can prevent offering an IP address to an attacker spoofing the same MAC address on a different remote ID. 5.0 Security Considerations DHCP as currently defined provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification in RFC 2131 [1]. This document introduces mechanisms to address several security attacks on the operation of IP address assignment, including IP spoofing, Client ID spoofing, MAC address spoofing, and DHCP server address exhaustion. It relies on an implied trusted relationship between the DHCP Relay Agent and the DHCP server, with an assumed untrusted DHCP client. It introduces a new identifer, the "Remote ID", that is also assumed to be trusted. The Remote ID is provided by the access network or modem and not by client premise equipment. Cryptographic or other techniques to authenticate the remote ID are certainly possible and encouraged, but are beyond the scope of this document. Expires October 1999 [Page 12] April 8, 1999 Note that any future mechanisms for authenticating DHCP client to server communications must take care to omit the DHCP Relay Agent option from server authentication calculations. This was the principal reason for organizing the DHCP Relay Agent Option as a single option with sub-options, and for requiring the relay agent to remove the option before forwarding to the client. While it is beyond the scope of this document to specify the general forwarding algorithm of public data circuit access units, note that automatic reforwarding of IP or ARP broadcast packets back downstream exposes serious IP security risks. For example, if an upstream broadcast DHCP-DISCOVER or DHCP-REQUEST were re-broadcast back downstream, any public host may easily spoof the desired DHCP server. 6.0 IANA Considerations IANA is required to maintain a new number space of "DHCP Relay Agent Sub-options", with the initial sub-options as described in this document. IANA MUST assign future DHCP Relay Agent Sub-options with a "IETF Consensus" policy as described in RFC 2434 [3]. Future proposed sub-options MUST be referenced symbolically in the internet-drafts that describe them, and shall be assigned numeric codes by IANA when and if the draft is approved by IESG for Proposed Standard RFC status. 7.0 References [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997. [2] Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor Extension" RFC 2132. [3] Narten,T. and Alvestrand, H. "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434. [4] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. 8.0 Glossary Expires October 1999 [Page 13] April 8, 1999 IANA Internet Assigned Numbers Authority LIS Logical IP Subnet MAC Message Authentication Code RAS Remote Access Server 9.0 Author's Address Michael Patrick Motorola Information Systems Group 20 Cabot Blvd., MS M4-30 Mansfield, MA 02048 Phone: (508) 261-5707 Email: mpatrick@dma.isg.mot.com Expires October 1999 [Page 14] From dhcp-v4@bucknell.edu Fri Apr 9 11:50:09 1999 Received: from marge.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03961 for ; Fri, 9 Apr 1999 11:50:04 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by marge.bucknell.edu (8.9.3/8.9.2) with SMTP id LAA04812; Fri, 9 Apr 1999 11:44:11 -0400 (EDT) Date: Fri, 9 Apr 1999 11:44:11 -0400 (EDT) Message-Id: <199904091544.LAA04812@marge.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: Donna.Maciolek@kp.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Donna Maciolek To: Multiple recipients of list Subject: Error message question from the field.... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Hello. I discovered your listserv on the IETF website when I was searching for the answer to the following question. Anyone out there who can answer it? Would be much appriciated! Thanks! Since migration to NetID, when I reboot my PC I always get Warning EventID 1002 in my Win NT4.0 Workstation Eventlog. It states: "DHCP received and unknown option 012 of length 010. The raw option data is given below." In DWORD form it looks like this: 0000: 35524357 39373936 3900. I have looked around for this EventID and for this DCHP option and have not found any real explanation of the error. Microsoft lists event 1002 as a DHCP error with no explanation that I can find. RFC 2132 lists default option 012 as "Option Host Name." Does this error message simply mean that my host (PC) name is not qualified within our local domain? These errors are filling up the logs on our servers also... There is no option 012 defined in NetID. We also use new Cicso Catalyst 1924 and Catalyst 5500 switches if that matters.... Any ideas? From dhcp-v4@bucknell.edu Fri Apr 9 14:31:37 1999 Received: from marge.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05802 for ; Fri, 9 Apr 1999 14:31:36 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by marge.bucknell.edu (8.9.3/8.9.2) with SMTP id OAA23587; Fri, 9 Apr 1999 14:27:08 -0400 (EDT) Date: Fri, 9 Apr 1999 14:27:08 -0400 (EDT) Message-Id: <370E2239.50941386@ehsco.com> Errors-To: droms@bucknell.edu Reply-To: ehall@ehsco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Eric A. Hall" To: Multiple recipients of list Subject: Re: Error message question from the field.... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.5 [en] (WinNT; I) Content-Transfer-Encoding: 7bit This is a product-specific question that would be best answered by the technical support group for NT. > It states: "DHCP received and unknown option 012 of length 010. > The raw option data is given below." > RFC 2132 lists default option 012 as "Option Host Name." NT cannot and will not use the hostname option. For more details, call the product support group for NT. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Fri Apr 9 16:25:21 1999 Received: from marge.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07074 for ; Fri, 9 Apr 1999 16:25:18 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by marge.bucknell.edu (8.9.3/8.9.2) with SMTP id QAA08689; Fri, 9 Apr 1999 16:21:23 -0400 (EDT) Date: Fri, 9 Apr 1999 16:21:23 -0400 (EDT) Message-Id: <199904092012.QAA24148@marge.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: Re: comments on dhcp-dns-09 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 message sent to dhcp-v4@bucknell.edu by LEWIS@TISLABS.COM follows. ------------------------------------------------------------------ At 4:54 PM -0400 4/6/1999, Mark Stapp wrote: >Edward, > >Thanks very much for your comments. I will forward your message to the dhcp >list along with this reply, if that's all right. I've cc'd all of your ccs >in case they're interested but not subscribed to the dhcp list. My reply's >inline: You can forward the comments. Here are some brief responses... >Would you like to see a general-purpose option that clients would use to >tell servers which DNS records they'd like added to their names? I can Not in this draft, at least. Perhaps you could place the DNS-opcode field before the RCODE's, making the format look like: Code Len Flags OPCODE RCODE data OPCODE RCODE data .... Where data is defined in a self terminating way per OPCODE. (For A records, this could be just a dname. For more complex ones, length and data would be in there.) But I'd recommend against saying more than this for now. Leave the door open to the possibility and see if people are able to extend it later. (Unless you think there's a problem controlling the changes.) I hate "mission creep" and "feature bloat," but I like extensiblity. >>o - A "Name collision" is an unfamiliar term to me. If you are concerned > >What I think I meant (though I may not have said it clearly) is pretty >specific: if two clients _think_ they should be using the same domain name, >and if they both try to update DNS to associate their IP addresses with >that name (or ask DHCP servers to associate them with the name), they >conflict. That's not the same case as an administrator's intentionally When two clients ask for the same name, is it a "decidable problem" to determine whether the same name request is due to desired round-robin use or an administrative error? Would a DHCP server then need be told what names are shared and which are unique? I'm not certain the DHCP server can make the distinction. >The kind of client you're describing is supported by the 09 draft. That The problem lies in paragrapgh 3 of section 3.3. If the client asks the server to not make updates, "the server MAY (at the determination of the local administrator) update the A RR." The word MAY has to become MUST NOT. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Network Associates/TIS Phone: +1 443-259-2352 Email: lewis@tislabs.com Think globally, scope locally. "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda Opinions expressed are property of my evil twin, not my employer. From dhcp-v4@bucknell.edu Sat Apr 10 02:05:21 1999 Received: from marge.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15145 for ; Sat, 10 Apr 1999 02:05:20 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by marge.bucknell.edu (8.9.3/8.9.2) with SMTP id CAA04997; Sat, 10 Apr 1999 02:03:00 -0400 (EDT) Date: Sat, 10 Apr 1999 02:03:00 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dblane@wal-mart.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Diana Lane To: Multiple recipients of list Subject: RE: comments on dhcp-dns-09 from a large production DDNS site X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 I apologize for the lack of attributions. Microsoft Outlook makes it difficult to tell who says what. When two clients ask for the same name, is it a "decidable problem" to determine whether the same name request is due to desired round-robin use or an administrative error? Would a DHCP server then need be told what names are shared and which are unique? I'm not certain the DHCP server can make the distinction. I would like to present an answer from the perspective of an organization with several tens of thousands of names in dynamically updatable zones. Given a zone on a server that supports dynamic updates, where some names in the zone belong to statically addressed servers performing business-critical functions, one does not want one's DHCP server(s) to blithely send updates that replace those servers' A records and PTR records with those of a DHCP client that happens to send the same hostname as the server in its DHCPREQUEST. That would be a Bad Thing. I have seen two vendors' approaches to the problem of name collisions. Neither meets my needs in supporting my customers. One approach is to disambiguate the name a client sends by appending extra characters if the name sent in the hostname option field is the same as an existing domain name. This has a rather nasty tendency to break certain applications that rely on a specific PTR record being returned. The other approach is to replace any existing resource record by that domain name with the new domain name and data, regardless of any other factors. This approach provides no protection against server names being usurped by PCs, printers, or other DHCP clients. I would like to see something such as the following process: * If the domain name does not already exist, add the new resource record. * If the domain name does exist, check for the existence of a TXT record with that domain name and a specific extension (say, "-noupdate"). * If that TXT record does not exist, update the client's A and PTR records. * If that TXT record does exist, DO NOT send any DNS updates and (at the administrator's discretion) send in the DHCPOFFER to the client a specific set of options defined as a policy (for example, a special domain name server that resolves all names to the IP address of an HTTP server whose default page is a set of instructions to the end user - not all deployed clients support a wide range of options so sending an http server option might not have the desired effect). There are some caveats associated with this approach: The initial DNS lookups and prerequisite queries would need to be performed before the DHCPOFFER so that any policy-specific options could be included in the DHCPOFFER. The actual update, if any, could be performed after the DHCPACK was sent in order to avoid updates for incomplete transactions. I do not know what effect this would have on server response time. In addition, Windows NT clients complain loudly via an obnoxious dialog box if they are sent options they did not request. This could be considered desirable as it will almost certainly result in the user opening a trouble ticket (which will lead to the client name being changed to something acceptable). Diana Lane Senior Network Engineer Wal-Mart Stores, Inc. 501/277-3177 "Be gentle to all, and stern with yourself." - Teresa of Avila From dhcp-v4@bucknell.edu Mon Apr 12 18:08:45 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08748 for ; Mon, 12 Apr 1999 18:08:44 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA27461; Mon, 12 Apr 1999 18:00:49 -0400 (EDT) Date: Mon, 12 Apr 1999 18:00:49 -0400 (EDT) Message-Id: <199904122047.QAA05866@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: WG Last Call for "The Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 This is a WG last call for "The Subnet Selection Option for DHCP", . This document has been revised according to the comments from the WG discussion in Minneapolis, 3/99. According to the consensus of the WG, the document is now in WG last call prior to submission for acceptance as a Proposed Standard. Please respond to the mailing list with comments by Friday, 4/23. - Ralph Droms From dhcp-v4@bucknell.edu Mon Apr 12 20:10:30 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09517 for ; Mon, 12 Apr 1999 20:10:29 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id UAA05451; Mon, 12 Apr 1999 20:03:41 -0400 (EDT) Date: Mon, 12 Apr 1999 20:03:41 -0400 (EDT) Message-Id: <199904122330.TAA02608@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Some minor and a few major nits on draft-ietf-dhc-subnet-option-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 My markups start with >>> at the beginning of the line. Mostly it's wordsmithing that you should feel free to ignore, but there are a few substantive changes that I think are important. I'm sorry for responding so close to the last call, but feel I can defend myself with the observation that it's only been out 19 days, so I'm being pretty speedy by IETF standards. _MelloN_ Network Working Group G. Waters INTERNET-DRAFT Nortel Networks March 1999 The Subnet Selection Option for DHCP Tuesday, March 23, 1999, 4:35 PM Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines a new DHCP option for selecting the subnet on which to allocate an address. This option would override a DHCP server's <<< normal methods of selecting which subnet on which to allocate an >>> normal methods of selecting the subnet on which to allocate an address for a client. Waters Expires: Mar 1999 + 6 months [Page 1] Internet Draft Subnet Selection Option March 1999 Table of Contents 1. Introduction......................................................2 2. Subnet Selection Option...........................................3 3. Intellectual Property.............................................4 4. Acknowledgements..................................................4 5. Security Considerations...........................................4 6. References........................................................4 7. Editor's Addresses................................................5 8. Full Copyright Statement..........................................5 1. Introduction This memo was produced by the DHCP Working Group and defines a new <<< DHCP option that specifies the subnet on which a DHCP server should >>> DHCP option that specifies the subnet that a DHCP server should use when selecting an address. This option takes precedence over other methods that the DHCP server may use to determine the subnet on which to select an address. Two existing methods of determining the subnet on which to select an address are: o To use the subnet address of the giaddr field in the DHCP packet, or if the giaddr field is zero; o To use the subnet address of the local interface on which the packet was received by the DHCP server. Methods other than the two described above may exist. <<< The subnet selection option is useful, but not limited to, the class >>> The subnet selection option is useful for, but not limited to, the class of devices that have a packet-handling plane (e.g.: switching, routing functionality) and a control plane (e.g.: device management and control functionality). The control plane is network connected and there is a DHCP server connected to that network. The packet-handling plane may or may not be network connected, however, in either case there is no network connected DHCP server available to this plane. The control plane is not network connected to the packet-handling plane, although the two planes may communicate using some method (e.g.: an internal data bus). <<< For the networks to which the packet-handling plane is connected, <<< there is a requirement to allocate addresses for devices connected to <<< those networks. >>> There is a requirement to allocate addresses for devices >>> connected to the networks to which the packet-handling plane >>> is connected. Since there is no network connectivity between the DHCP server and the packet-handling plane, the control plane must allocate addresses using the DHCP on behalf of the packet-handling plane. Because the control <<< plane is requesting the addresses, the DHCP server would normally have <<< the undesired result of allocating the address on the subnet on which <<< the control plane is connected. >>> plane is requesting the addresses, the DHCP server would normally >>> allocate the address on the subnet on which the control plane is >>> connected, which would be incorrect. Waters Expires: Mar 1999 + 6 months [Page 2] Internet Draft Subnet Selection Option March 1999 If the option specified by this memo is included in the DHCPDISCOVER/DHCPREQUEST message then the server should allocate an address on the subnet or network segment that is specified by this option. The option would specify an address of one of the packet- handling plane's subnets. >>> (the above should be "an address on" or "the address of.") The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Subnet Selection Option The subnet selection option is a DHCP option. The option contains a single IP address that is the address of a subnet. The value for the subnet address is determined by taking any IP address on the subnet and ANDing that address with the subnet mask (i.e.: the network and subnet bits are left alone and the remaining (address) bits are set to zero). When this option is present, the DHCP server MUST use either the: o The subnet specified in the option, or; >>> o A subnet on the same network segment as the subnet specified in the option; on which to allocate an address. The format of the option is: Code Len IP Address +-----+-----+-----+-----+-----+-----+ | TBD | 4 | A1 | A2 | A3 | A4 | +-----+-----+-----+-----+-----+-----+ <<< In order to ensure backwards compatibility of clients that do support <<< this option when communicating with DHCP servers that do not support <<< this option, the DHCP client SHOULD check that an allocated address in <<< on the requested subnet or network segment. The client SHOULD NOT <<< respond to a DHCPOFFER or DHCPACK of an address that is not on the <<< respond to a DHCPOFFER for an address that is not on the <<< requested subnet or network segment. >>> (You can't really do this, because the server may choose to >>> allocate an IP address on a different subnet that's on the same >>> network segment, and the client doesn't know the network topology >>> and so can't distinguish this from the behaviour of a >>> non-conforming server. If you want this to work, you probably >>> need something like the following.) >>> Servers supporting this option MUST return the option to any >>> client that sends it, regardless of whether or not the client >>> requests it in a parameter request list. Clients using this >>> option must discard DHCPOFFER packets that do not contain it. >>> (you also probably should just nuke the entire next paragraph, or >>> else you're going to find yourself in a Monty Python Spanish >>> Inquisition skit.) <<< This option does not require any change to other operations or >>> This option does not require changes to operations or features of the DHCP server other than to select the subnet on which to allocate an address. For example, the handling of DHCPDISCOVER for an unknown subnet may continue to operate unchanged. When this option is present and the server supports this option, the server MUST NOT offer an address that is not on the requested subnet or network segment. Waters Expires: Mar 1999 + 6 months [Page 3] Internet Draft Subnet Selection Option March 1999 <<< Existing methods for determining where to send a reply to a DHCP <<< client are not changed when this option is present in a request. >>> The DHCP server MUST use the same algorithm for choosing the >>> IP address to which to send a reply whether or not this option >>> is present in a request. 3. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 4. Acknowledgements This document is the result of work undertaken the by DHCP working group. Thanks to Tim Aston and Ralph Droms for reviewing this memo. 5. Security Considerations DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed is section 7 of the protocol specification [RFC2131]. 6. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. Waters Expires: Mar 1999 + 6 months [Page 4] Internet Draft Subnet Selection Option March 1999 7. Editor's Addresses Glenn Waters Nortel Networks 310-875 Carling Avenue, Ottawa, Ontario K1S 5P1 Canada Phone: +1 613-798-4925 Email: gww@nortelnetworks.com 8. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Waters Expires: Mar 1999 + 6 months [Page 5] From dhcp-v4@bucknell.edu Tue Apr 13 10:41:43 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23159 for ; Tue, 13 Apr 1999 10:41:41 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA20662; Tue, 13 Apr 1999 10:21:05 -0400 (EDT) Date: Tue, 13 Apr 1999 10:21:05 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: ndlane@wal-mart.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Nathan Lane To: Multiple recipients of list Subject: RE: Some minor and a few major nits on draft-ietf-dhc-subnet-opti X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 Sorry I'm in so late on this. I propose a more significant change. If we have to encode clients with an IP network preference, we open up a significant amount of work by the configurator of said devices. I suggest adding a "flags" field in this option that would indicate a policy preference, significantly expanding its usefulness for me while preserving the core functionality of this draft. i.e.: The format of the option is: Code Len Flags IP Address +-----+-----+-----+-----+-----+-----+-----+ | TBD | 4 | F1 |A1 | A2 | A3 | A4 | +-----+-----+-----+-----+-----+-----+-----+ I can only think of three flags right now: 0 Next field indicates IP network preference, four octets 1 Desire RFC-1918 private class address, IP network preference may be indicated as 0.0.0.0 2 Desire public address, IP network preference may be 0.0.0.0 The flags section would make this option useful to me. Otherwise it simply adds a non-trivial amount of work for our installers and makes a device configured such inappopriate for mobile use. With my changes, the client can request I also really don't like the client requirements section stating that a device must ignore the DHCPOFFER. Section 2 should add "if after X time period the DHCP client does not receive a DHCPOFFER containing this option, it MUST stop sending DHCPDISCOVER's with the option set [and unset the option to accept a regular DHCPOFFER]". The addition in "[]" is a possible addition. The point is I don't want to see open interpretations of this where the device goes into a DHCPDISCOVER spin loop at rapid-fire intervals. -Nathan Lane Senior Network Engineer Wal-Mart Stores, Inc. (501) 277-5786 > -----Original Message----- > From: Ted Lemon [SMTP:mellon@isc.org] > Sent: Monday, April 12, 1999 7:05 PM > To: Multiple recipients of list > Subject: Some minor and a few major nits on > draft-ietf-dhc-subnet-option-01.txt > > Network Working Group G. Waters > INTERNET-DRAFT Nortel Networks > March 1999 > > > > > > The Subnet Selection Option for DHCP > > > > Tuesday, March 23, 1999, 4:35 PM > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with all > provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering Task > Force (IETF), its areas, and its working groups. Note that other > groups may also distribute working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > To learn the current status of any Internet-Draft, please check the > "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow > Directories on ds.internic.net (US East Coast), nic.nordu.net > (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). > > Copyright Notice > > Copyright (C) The Internet Society (1999). All Rights Reserved. > > Abstract > > This memo defines a new DHCP option for selecting the subnet on which > to allocate an address. This option would override a DHCP server's > <<< normal methods of selecting which subnet on which to allocate an > >>> normal methods of selecting the subnet on which to allocate an > address for a client. > > > > > > > > > > > > > > Waters Expires: Mar 1999 + 6 months [Page 1] > > Internet Draft Subnet Selection Option March 1999 > > > Table of Contents > > 1. Introduction......................................................2 > 2. Subnet Selection Option...........................................3 > 3. Intellectual Property.............................................4 > 4. Acknowledgements..................................................4 > 5. Security Considerations...........................................4 > 6. References........................................................4 > 7. Editor's Addresses................................................5 > 8. Full Copyright Statement..........................................5 > > > > 1. Introduction > > This memo was produced by the DHCP Working Group and defines a new > <<< DHCP option that specifies the subnet on which a DHCP server should > >>> DHCP option that specifies the subnet that a DHCP server should > use when selecting an address. This option takes precedence over > other methods that the DHCP server may use to determine the subnet on > which to select an address. Two existing methods of determining the > subnet on which to select an address are: > > o To use the subnet address of the giaddr field in the DHCP packet, > or if the giaddr field is zero; > > o To use the subnet address of the local interface on which the > packet was received by the DHCP server. > > Methods other than the two described above may exist. > > <<< The subnet selection option is useful, but not limited to, the class > >>> The subnet selection option is useful for, but not limited to, the > class > of devices that have a packet-handling plane (e.g.: switching, routing > functionality) and a control plane (e.g.: device management and > control functionality). The control plane is network connected and > there is a DHCP server connected to that network. The packet-handling > plane may or may not be network connected, however, in either case > there is no network connected DHCP server available to this plane. The > control plane is not network connected to the packet-handling plane, > although the two planes may communicate using some method (e.g.: an > internal data bus). > > <<< For the networks to which the packet-handling plane is connected, > <<< there is a requirement to allocate addresses for devices connected > to > <<< those networks. > >>> There is a requirement to allocate addresses for devices > >>> connected to the networks to which the packet-handling plane > >>> is connected. > > Since there is no network connectivity between the DHCP server and the > packet-handling plane, the control plane must allocate addresses using > the DHCP on behalf of the packet-handling plane. Because the control > <<< plane is requesting the addresses, the DHCP server would normally > have > <<< the undesired result of allocating the address on the subnet on > which > <<< the control plane is connected. > >>> plane is requesting the addresses, the DHCP server would normally > >>> allocate the address on the subnet on which the control plane is > >>> connected, which would be incorrect. > > > > Waters Expires: Mar 1999 + 6 months [Page 2] > > Internet Draft Subnet Selection Option March 1999 > > > If the option specified by this memo is included in the > DHCPDISCOVER/DHCPREQUEST message then the server should allocate an > address on the subnet or network segment that is specified by this > option. The option would specify an address of one of the packet- > handling plane's subnets. > >>> (the above should be "an address on" or "the address of.") > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > 2. Subnet Selection Option > > The subnet selection option is a DHCP option. The option contains a > single IP address that is the address of a subnet. The value for the > subnet address is determined by taking any IP address on the subnet > and ANDing that address with the subnet mask (i.e.: the network and > subnet bits are left alone and the remaining (address) bits are set to > zero). When this option is present, the DHCP server MUST use either > the: > > o The subnet specified in the option, or; > >>> > o A subnet on the same network segment as the subnet specified in the > option; > > on which to allocate an address. > > The format of the option is: > > Code Len IP Address > +-----+-----+-----+-----+-----+-----+ > | TBD | 4 | A1 | A2 | A3 | A4 | > +-----+-----+-----+-----+-----+-----+ > > > <<< In order to ensure backwards compatibility of clients that do > support > <<< this option when communicating with DHCP servers that do not support > <<< this option, the DHCP client SHOULD check that an allocated address > in > <<< on the requested subnet or network segment. The client SHOULD NOT > <<< respond to a DHCPOFFER or DHCPACK of an address that is not on the > <<< respond to a DHCPOFFER for an address that is not on the > <<< requested subnet or network segment. > >>> (You can't really do this, because the server may choose to > >>> allocate an IP address on a different subnet that's on the same > >>> network segment, and the client doesn't know the network topology > >>> and so can't distinguish this from the behaviour of a > >>> non-conforming server. If you want this to work, you probably > >>> need something like the following.) > > >>> Servers supporting this option MUST return the option to any > >>> client that sends it, regardless of whether or not the client > >>> requests it in a parameter request list. Clients using this > >>> option must discard DHCPOFFER packets that do not contain it. > > >>> (you also probably should just nuke the entire next paragraph, or > >>> else you're going to find yourself in a Monty Python Spanish > >>> Inquisition skit.) > > <<< This option does not require any change to other operations or > >>> This option does not require changes to operations or > features of the DHCP server other than to select the subnet on which > to allocate an address. For example, the handling of DHCPDISCOVER for > an unknown subnet may continue to operate unchanged. > > When this option is present and the server supports this option, the > server MUST NOT offer an address that is not on the requested subnet > or network segment. > > > > > Waters Expires: Mar 1999 + 6 months [Page 3] > > Internet Draft Subnet Selection Option March 1999 > > > <<< Existing methods for determining where to send a reply to a DHCP > <<< client are not changed when this option is present in a request. > >>> The DHCP server MUST use the same algorithm for choosing the > >>> IP address to which to send a reply whether or not this option > >>> is present in a request. > > 3. Intellectual Property > > The IETF takes no position regarding the validity or scope of any > intellectual property or other rights that might be claimed to pertain > to the implementation or use of the technology described in this > document or the extent to which any license under such rights might or > might not be available; neither does it represent that it has made any > effort to identify any such rights. Information on the IETF's > procedures with respect to rights in standards-track and standards- > related documentation can be found in BCP-11. > > Copies of claims of rights made available for publication and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this specification > can be obtained from the IETF Secretariat. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights which may cover technology that may be required to practice > this standard. Please address the information to the IETF Executive > Director. > > > 4. Acknowledgements > > This document is the result of work undertaken the by DHCP working > group. Thanks to Tim Aston and Ralph Droms for reviewing this memo. > > > 5. Security Considerations > > DHCP currently provides no authentication or security mechanisms. > Potential exposures to attack are discussed is section 7 of the > protocol specification [RFC2131]. > > > 6. References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", RFC 2119, BCP 14, March 1997. > > [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, > March 1997. > > [RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor > Extensions", RFC 2132, March 1997. > > > > Waters Expires: Mar 1999 + 6 months [Page 4] > > Internet Draft Subnet Selection Option March 1999 > > > 7. Editor's Addresses > > Glenn Waters > Nortel Networks > 310-875 Carling Avenue, > Ottawa, Ontario K1S 5P1 > Canada > > Phone: +1 613-798-4925 > Email: gww@nortelnetworks.com > > > 8. Full Copyright Statement > > Copyright (C) The Internet Society (1999). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published and > distributed, in whole or in part, without restriction of any kind, > provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of developing > Internet standards in which case the procedures for copyrights defined > in the Internet Standards process must be followed, or as required to > translate it into languages other than English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT > NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN > WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > > > > > > > > > > > > > > > Waters Expires: Mar 1999 + 6 months [Page 5] > From dhcp-v4@bucknell.edu Tue Apr 13 11:53:25 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23688 for ; Tue, 13 Apr 1999 11:53:23 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA19264; Tue, 13 Apr 1999 11:45:18 -0400 (EDT) Date: Tue, 13 Apr 1999 11:45:18 -0400 (EDT) Message-Id: <199904131455.KAA00210@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Suggested changes to RFC2132 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 In RFC2132, in section 2, paragraph 1, there is a requirement as follows: "Options containing NVT ASCII data SHOULD NOT include a trailing NULL; however, the receiver of such options MUST be prepared to delete trailing nulls if they exist. The receiver MUST NOT require that a trailing null be included in the data." This text should be deleted, and no text added to address this problem. In order to implement this requirement, the DHCP server or client needs to know which options are stored in NVT ASCII. Some options (e.g., the DHCP client identifier) may be either NVT ASCII or binary, depending on the context. Also, new options may be developed in the future, and there is no guarantee that existing servers will know their format. So it is not reasonable to assume that the server or client will always know that an option's format is or is not NVT ASCII. This requirement is here solely to accomodate broken Windows 95 clients, AFAIK. Because it is present I have had several people say to me that the broken Windows 95 client is in fact in compliance with the standard because this requirement is stated in the specification. I don't believe it is an error for a DHCP server to try to deal correctly with clients that send NUL-terminated NVT ASCII strings, but in fact the disputed requirement doesn't completely specify this - in order to interoperate with broken Microsoft DHCP clients, the DHCP server must in fact always NUL-terminate NVT ASCII strings that it sends to the client. Because this statement is only present to accomodate a buggy client, because the implementation of the required behaviour is complicated, because the statement doesn't completely specify the correct behaviour, and because complete correctness would be impossible to demonstrate, this requirement does not belong in the standard. I think the old maxim, "be liberal in what you accept, and conservative in what you send" addresses this issue to the extent that it needs to be addressed. If not, a complete description of the problem and its suggested solution should go in a document on best current practices or implementation considerations. It should _not_ be a SHOULD or a MUST in the standard. _MelloN_ From dhcp-v4@bucknell.edu Tue Apr 13 11:53:48 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23699 for ; Tue, 13 Apr 1999 11:53:47 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA17528; Tue, 13 Apr 1999 11:48:31 -0400 (EDT) Date: Tue, 13 Apr 1999 11:48:31 -0400 (EDT) Message-Id: <199904131528.LAA00607@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Some minor and a few major nits on draft-ietf-dhc-subnet-opti X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 I think you've misapprehended the purpose of the subnet specification option. It's not intended for use by regular clients, like your laptop running Win98. It's also not intended to choose which subnet to use on a network segment on which more than one subnet is running. It's intended so that something like a relay agent that has no IP address of its own on the network segment to which the client is attached can send a DHCP request on behalf of that client and specify the network segment to which that client is attached. Essentially, it's intended to function just like giaddr, except that the server doesn't send the response back to the address specified in the subnet specification option. WRT client subnet selection, it sounds like you're looking to configure the client with a hint to the server about what subnet to choose. This is probably more correctly addressed by the user class identifier option (draft-ietf-dhc-userclass-??.txt). Unfortunately, Microsoft doesn't yet implement the user class option, AFAIK, so this is somewhat academic for a large class of potential clients. :'( _MelloN_ From dhcp-v4@bucknell.edu Tue Apr 13 18:29:58 1999 Received: from marge.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00601 for ; Tue, 13 Apr 1999 18:29:57 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by marge.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA18031; Tue, 13 Apr 1999 18:18:54 -0400 (EDT) Date: Tue, 13 Apr 1999 18:18:54 -0400 (EDT) Message-Id: <4.1.19990413231427.02fcd9d0@dokka.maxware.no> Errors-To: droms@bucknell.edu Reply-To: Harald@Alvestrand.no Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Harald Tveit Alvestrand To: Multiple recipients of list Subject: Re: DHCP Relay Agent Options -06 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Before I forget again (apologies for the delay): The two paragraphs seem fine with me. Thanks for caring! Harald A At 11:05 08.04.99 -0400, Michael W. Patrick wrote: >Harald, > >I'm attaching what I'd like to submit as rev -06 of the agent options >draft, with only slight rewording of the two paragraphs we've been >discussing privately. > >Harald, is my revised wording of the paragraphs OK with you? > >Any other major objections? Both paragraphs are explanatory in nature, >and do not have spec wording. > >Here are the two new paragraphs: > >In 1.1: > Note that using this method to obtain IP addresses means that IP > addresses can only be obtained while communication to the central > site is available. Some host lan installations may use a local DHCP > server or other methods to obtain IP addresses for in-house use. > >In 5.0: > While it is beyond the scope of this document to specify the general > forwarding algorithm of public data circuit access units, note that > automatic reforwarding of IP or ARP broadcast packets back downstream > exposes serious IP security risks. For example, if an upstream > broadcast DHCP-DISCOVER or DHCP-REQUEST were re-broadcast back > downstream, any public host may easily spoof the desired DHCP server. > >Regards, >-mike > > > > > > > >DHC Working Grop Michael Patrick > Motorola ING > April 8, 1999 > > > DHCP Relay Agent Information Option > >Status of this Memo > > This document is an Internet Draft. Internet Drafts are working > documents of the Internet Engineering Task Force (IETF), its Areas, > and its Working Groups. Note that other groups may also distribute > working documents as Internet Drafts. > > Internet Drafts are draft documents valid for a maximum of six > months. Internet Drafts may be updated, replaced, or obsoleted by > other documents at any time. It is not appropriate to use Internet > Drafts as reference material or to cite them other than as a "working > draft" or "work in progress." > > Please check the "1id-abstracts.txt" listing contained in the > Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), > nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net > (US East Coast), or ftp.isi.edu (US West Coast). > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [4]. > >Abstract > > Newer high-speed public Internet access technologies call for a > high-speed modem to have a LAN attachment to one or more customer > premise hosts. It is advantageous to use the Dynamic Host > Configuration Protocol as defined in RFC 2131 [1] to assign customer > premise host IP addresses in this environment. However, a number of > security and scaling problems arise with such "public" DHCP use. > This document describes a new DHCP option to address these issues. > This option extends the set of DHCP options as defined in RFC 2132 > [2]. > > The new option is called the Relay Agent Information option and is > inserted by the DHCP relay agent when forwarding client-originated > DHCP packets to a DHCP server. Servers recognizing the Relay Agent > Information option may use the information to implement IP address or > other parameter assignment policies. The DHCP Server echoes the > option back verbatim to the relay agent in server-to-client replies, > and the relay agent strips the option before forwarding the reply to > > > >Expires October 1999 [Page 1] > > > > > > April 8, 1999 > > > the client. > > The "Relay Agent Information" option is organized as a single DHCP > option that contains one or more "sub-options" that convey > information known by the relay agent. The initial sub-options are > defined for a relay agent that is co-located in a public circuit > access unit. These include a "circuit ID" for the incoming circuit, > a "remote ID" which provides a trusted identifier for the remote > high-speed modem, and the "subnet mask" of the logical IP subnet from > which the relay agent received the client DHCP packet. > >Table of Contents > > > 1 Introduction........................................... 3 > 1.1 High-Speed Circuit Switched Data Networks.............. 3 > 1.2 DHCP Relay Agent in the Circuit Access Equipment....... 5 > 2.0 Relay Agent Information Option......................... 6 > 2.1 Agent Operation........................................ 7 > 2.1.1 Reforwarded DHCP requests............................ 8 > 2.2 Server Operation....................................... 8 > 3.0 Relay Agent Information Suboptions..................... 9 > 3.1 Agent Circuit ID....................................... 9 > 3.2 Agent Remote ID........................................ 10 > 3.3 Agent Subnet Mask...................................... 11 > 4.0 Issues Resolved........................................ 11 > 5.0 Security Considerations................................ 12 > 6.0 IANA Considerations.................................... 13 > 7.0 References............................................. 13 > 8.0 Glossary............................................... 13 > 9.0 Author's Address....................................... 14 > > > > > Revision History > > Rev Date Description > --- -------- ----------- > -06 4/8/99 Added editorial paragraph at end of 1.1 noting > that some host lan installations may not rely > on a centralized DHCP server. > > Added editorial pararaph at end of 5.0 noting > the security risks of automatically reforward- > ing IP/ARP packets back downstream. > > > > > >Expires October 1999 [Page 2] > > > > > > April 8, 1999 > > >1 Introduction > >1.1 High-Speed Circuit Switched Data Networks > > Public Access to the Internet is usually via a circuit switched data > network. Today, this is primarily implemented with dial-up modems > connecting to a Remote Access Server. But higher speed circuit > access networks also include ISDN, ATM, Frame Relay, and Cable Data > Networks. All of these networks can be characterized as a "star" > topology where multiple users connect to a "circuit access unit" via > switched or permanent circuits. > > With dial-up modems, only a single host PC attempts to connect to the > central point. The PPP protocol is widely used to assign IP > addresses to be used by the single host PC. > > The newer high-speed circuit technologies, however, frequently > provide a LAN interface (especially Ethernet) to one or more host > PCs. It is desirable to support centralized assignment of the IP > addresses of host computers connecting on such circuits via DHCP. > The DHCP server can be, but usually is not, co-implemented with the > centralized circuit concentration access device. The DHCP server is > often connected as a separate server on the "Central LAN" to which > the central access device (or devices) attach. > > A common physical model for high-speed Internet circuit access is > shown in Figure 1, below. > > > > > > > > > > > > > > > > > > > > > > > > >Expires October 1999 [Page 3] > > > > > > April 8, 1999 > > > > > > +---------------+ | > Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host A > LAN | | Access | Lan |- Host B > | | Unit 1 | |- Host C > |-----| |-- | > | |(relay agent) |... > +---------+ | +---------------+ > | DHCP |--| > | Server | | > +---------+ | > | > | +---------------+ > +---------+ | | Circuit |-- ckt 1--- Modem2-- Host--- Host D > | Other | | | Access | Lan > | Servers |--|-----| Unit 2 | > | (Web, | | | |-- ckt 2--- Modem3-- Host--- Host E > | DNS) | | |(relay agent) |... Lan > | | +---------------+ > +---------+ > Figure 1: DHCP High Speed Circuit Access Model > > > Note that in this model, the "modem" connects to a LAN at the user > site, rather than to a single host. Multiple hosts are implemented at > this site. Although it is certainly possible to implement a full IP > router at the user site, this requires a relatively expensive piece > of equipment (compared to typical modem costs). Furthermore, a > router requires an IP address not only for every host, but for the > router itself. Finally, a user-side router requires a dedicated > Logical IP Subnet (LIS) for each user. While this model is > appropriate for relatively small corporate networking environments, > it is not appropriate for large, public accessed networks. In this > scenario, it is advantageous to implement an IP networking model that > does not allocate an IP address for the modem (or other networking > equipment device at the user site), and especially not an entire LIS > for the user side LAN. > > Note that using this method to obtain IP addresses means that IP > addresses can only be obtained while communication to the central > site is available. Some host lan installations may use a local DHCP > server or other methods to obtain IP addresses for in-house use. > > > > > > > >Expires October 1999 [Page 4] > > > > > > April 8, 1999 > > >1.2 DHCP Relay Agent in the Circuit Access Unit > > It is desirable to use DHCP to assign the IP addresses for public > high-speed circuit access. A number of circuit access units (e.g. > RAS's, cable modem termination systems, ADSL access units, etc) > connect to a LAN (or local internet) to which is attached a DHCP > server. > > For scaling and security reasons, it is advantageous to implement a > "router hop" at the circuit access unit, much like high-capacity > RAS's do today. The circuit access equipment acts as both a router > to the circuits and as the DHCP relay agent. > > The advantages of co-locating the DHCP relay agent with the circuit > access equipment are: > > DHCP broadcast replies can be routed to only the proper circuit, > avoiding, say, the replication of the DCHP reply broadcast onto > thousands of access circuits; > > The same mechanism used to identify the remote connection of the > circuit (e.g. a user ID requested by a Remote Access Server acting as > the circuit access equipment) may be used as a host identifier by > DHCP, and used for parameter assignment. This includes centralized > assignment of IP addresses to hosts. This provides a secure remote > ID from a trusted source -- the relay agent. > > A number of issues arise when forwarding DHCP requests from hosts > connecting publicly accessed high-speed circuits with LAN connections > at the host. Many of these are security issues arising from DHCP > client requests from untrusted sources. How does the relay agent > know to which circuit to forward replies? How does the system > prevent DHCP IP exhaustion attacks? This is when an attacker > requests all available IP addresses from a DHCP server by sending > requests with fabricated client MAC addresses. How can an IP address > or LIS be permanently assigned to a particular user or modem? How > does one prevent "spoofing" of client identifer fields used to assign > IP addresses? How does one prevent denial of service by "spoofing" > other client's MAC addresses? > > All of these issues may be addressed by having the circuit access > equipment, which is a trusted component, add information to DHCP > client requests that it forwards to the DHCP server. > > > > > > > > >Expires October 1999 [Page 5] > > > > > > April 8, 1999 > > >2.0 Relay Agent Information Option > > This document defines a new DHCP Option called the Relay Agent > Information Option. It is a "container" option for specific agent- > supplied sub-options. The format of the Relay Agent Information > option is: > > > Code Len Agent Information Field > +------+------+------+------+------+------+--...-+------+ > | 82 | N | i1 | i2 | i3 | i4 | | iN | > +------+------+------+------+------+------+--...-+------+ > > The length N gives the total number of octets in the Agent > Information Field. The Agent Information field consists of a sequence > of SubOpt/Length/Value tuples for each sub-option, encoded in the > following manner: > > > SubOpt Len Sub-option Value > +------+------+------+------+------+------+--...-+------+ > | 1 | N | s1 | s2 | s3 | s4 | | sN | > +------+------+------+------+------+------+--...-+------+ > SubOpt Len Sub-option Value > +------+------+------+------+------+------+--...-+------+ > | 2 | N | i1 | i2 | i3 | i4 | | iN | > +------+------+------+------+------+------+--...-+------+ > > > No "pad" sub-option is defined, and the Information field shall NOT > be terminated with a 255 sub-option. The length N of the DHCP Agent > Information Option shall include all bytes of the sub-option > code/length/value tuples. Since at least one sub-option must be > defined, the minimum Relay Agent Information length is two (2). The > length N of the sub-options shall be the number of octets in only > that sub-option's value field. A sub-option length may be zero. The > sub-options need not appear in sub-option code order. > > > The initial assignment of DHCP Relay Agent Sub-options is as follows: > > > DHCP Agent Sub-Option Descrption > Sub-option Code > --------------- ---------------------- > 1 Agent Circuit ID Sub-option > 2 Agent Remote ID Sub-option > 3 Agent Subnet Mask Sub-option > > > >Expires October 1999 [Page 6] > > > > > > April 8, 1999 > > > New sub-option codes MUST be assigned by IANA according to the policy > described in the "IANA Considerations" section of this document. > >2.1 Agent Operation > > Overall adding of the DHCP relay agent option SHOULD be configurable, > and SHOULD be disabled by default. Relay agents SHOULD have separate > configurables for each sub-option to control whether it is added to > client-to-server packets. > > A DHCP relay agent adding a Relay Agent Information field SHALL add > it as the last DHCP agent option in the DHCP options field of any > recognized DHCP packet forwarded from a client to a server. Such > additions shall be made for only those packets recognized as DHCP; > BOOTP-only packets shall not be affected. > > Relay agents receiving a DHCP packet with giaddr set to zero > (indicating that they are the first-hop router) but with a Relay > Agent Information option already present in the packet SHALL discard > the packet and increment an error count. > > Relay agents MAY have a configurable for the maximum size of the DHCP > packet to be created after appending the Agent Information option. > Packets which, after appending the Relay Agent Information option, > would exceed this configured maximum size shall be forwarded WITHOUT > adding the Agent Information option. An error counter SHOULD be > incremented in this case. In the absence of this configurable, the > agent SHALL NOT increase a forwarded DHCP packet size to exceed the > MTU of the interface on which it is forwarded. > > The Relay Agent Information option echoed by a server MUST be removed > by the agent when forwarding a server-to-client response back to the > client. > > The agent SHALL NOT add an "Option Overload" option to the packet or > use the "file" or "sname" fields for adding Relay Agent Information > option. It SHALL NOT parse or remove Relay Agent Information options > that may appear in the sname or file fields of a server-to-client > packet forwarded through the agent. > > The operation of relay agents for specific sub-options is specified > with that sub-option. > > Relay agents are NOT required to monitor or modify client-originated > DHCP packets addressed to a server unicast address. This includes > the DHCP-REQUEST sent when entering the RENEWING state. > > > > > >Expires October 1999 [Page 7] > > > > > > April 8, 1999 > > >2.1.1 Reforwarded DHCP requests > > A DHCP relay agent may receive a client DHCP packet forwarded from a > BOOTP/DHCP relay agent closer to the client. Such a packet will have > giaddr as non-zero, and may or may not already have a DHCP Relay > Agent option in it. > > Relay agents configured to add a Relay Agent option which receive a > client DHCP packet with a nonzero giaddr SHALL discard the packet if > the giaddr spoofs a giaddr address implemented by the local agent > itself. > > Otherwise, the relay agent SHALL forward any received DHCP packet > with a valid non-zero giaddr WITHOUT adding any relay agent options. > Per RFC 2131, it shall also NOT modify the giaddr value. > > >2.2 Server Operation > > DHCP servers unaware of the Relay Agent Information option will > ignore the option upon receive and will not echo it back on > responses. This is the specified server behavior for unknown > options. > > DHCP servers claiming to support the Relay Agent Information option > SHALL echo the entire contents of the Relay Agent Information option > in all replies. Servers SHOULD copy the Relay Agent Information > option as the last DHCP option in the response. Servers SHALL NOT > place the echoed Relay Agent Information option in the overloaded > sname or file fields. If a server is unable to copy a full Relay > Agent Information field into a response, it SHALL send the response > without the Relay Information Field, and SHOULD increment an error > counter for the situation. > > The operation of DHCP servers for specific sub-options is specified > with that sub-option. > > Note that DHCP relay agents are not required to monitor unicast DHCP > messages sent directly between the client and server (i.e, those that > aren't sent via a relay agent). However, some relay agents MAY chose > to do such monitoring and add relay agent options. Consequently, > servers SHOULD be prepared to handle relay agent options in unicast > messages, but MUST NOT expect them to always be there. > > > > > > > > >Expires October 1999 [Page 8] > > > > > > April 8, 1999 > > >3.0 Relay Agent Information Sub-options > >3.1 Agent Circuit ID Sub-option > > This sub-option MAY be added by DHCP relay agents which terminate > switched or permanent circuits. It encodes an agent-local identifier > of the circuit from which a DHCP client-to-server packet was > received. It is intended for use by agents in relaying DHCP > responses back to the proper circuit. Possible uses of this field > include > - Router interface number > - Switching Hub port number > - Remote Access Server port number > - Frame Relay DLCI > - ATM virtual circuit number > - Cable Data virtual circuit number > > Servers MAY use the Circuit ID for IP and other parameter assignment > policies. The Circuit ID SHOULD be considered an opaque value, with > policies based on exact string match only; that is, the Circuit ID > SHOULD NOT be internally parsed by the server. > > The DHCP server SHOULD report the Agent Circuit ID value of current > leases in statistical reports (including its MIB) and in logs. Since > the Circuit ID is local only to a particular relay agent, a circuit > ID should be qualified with the giaddr value that identifies the > relay agent. > > > SubOpt Len Circuit ID > +------+------+------+------+------+------+------+------+-- > | 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ... > +------+------+------+------+------+------+------+------+-- > > > > > > > > > > > > > > > > > > >Expires October 1999 [Page 9] > > > > > > April 8, 1999 > > >3.2 Agent Remote ID Sub-option > > This sub-option MAY be added by DHCP relay agents which terminate > switched or permanent circuits and have mechanisms to identify the > remote host end of the circuit. The Remote ID field may be used to > encode, for instance: > -- a "caller ID" telephone number for dial-up connection > -- a "user name" prompted for by a Remote Access Server > -- a remote caller ATM address > -- a "modem ID" of a cable data modem > -- the remote IP address of a point-to-point link > -- a remote X.25 address for X.25 connections > > The remote ID MUST be globally unique. > > DHCP servers MAY use this option to select parameters specific to > particular users, hosts, or subscriber modems. The option SHOULD be > considered an opaque value, with policies based on exact string match > only; that is, the option SHOULD NOT be internally parsed by the > server. > > The relay agent MAY use this field in addition to or instead of the > Agent Circuit ID field to select the circuit on which to forward the > DHCP reply (e.g. Offer, Ack, or Nak). DHCP servers SHOULD report this > value in any reports or MIBs associated with a particular client. > > > > SubOpt Len Agent Remote ID > +------+------+------+------+------+------+------+------+-- > | 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ... > +------+------+------+------+------+------+------+------+-- > > > > > > > > > > > > > > > > > > > >Expires October 1999 [Page 10] > > > > > > April 8, 1999 > > >3.3 Agent Subnet Mask Sub-option > > This sub-option MAY be added by DHCP relay agents to identify the > subnet mask of the Logical IP Subnet (LIS) from which the client DHCP > packet was received. The LIS of the client is defined as the subnet > formed by the giaddr ANDed with the Agent Subnet Mask. > > Servers MAY use this mask field to automatically create scopes of > assignable IP addresses. Use of this field avoids the need to have > identical configuration of the logical IP subnets on which clients > reside in both the relaying routers and the DHCP server. In this > case, the router configuration defines the LISs, and the DHCP servers > automatically discover the LISs from the relay agent options of > forwarded client DHCP requests. > > > > SubOpt Len Agent Subnet Mask > +------+------+------+------+------+------+ > | 3 | 4 | m1 | m2 | m3 | m4 | > +------+------+------+------+------+------+ > > > > >4.0 Issues Resolved > > Broadcast Forwarding > > The circuit access equipment forwards the normally broadcasted > DHCP response only on the circuit indicated in the Agent Circuit > ID. > > DHCP Address Exhaustion > > In general, the DHCP server may be extended to maintain a database > with the "triplet" of > > > (client IP address, client MAC address, client remote ID) > > > The DHCP server SHOULD implement policies that restrict the number > of IP addresses to be assigned to a single remote ID. > > > > > > > >Expires October 1999 [Page 11] > > > > > > April 8, 1999 > > > Static Assignment > > The DHCP server may use the remote ID to select the IP address to > be assigned. It may permit static assignment of IP addresses to > particular remote IDs, and disallow an address request from an > unauthorized remote ID. > > > IP Spoofing > > The circuit access device may associate the IP address assigned by > a DHCP server in a forwarded DHCP Ack packet with the circuit to > which it was forwarded. The circuit access device MAY prevent > forwarding of IP packets with source IP addresses -other than- > those it has associated with the receiving circuit. This prevents > simple IP spoofing attacks on the Central LAN, and IP spoofing of > other hosts. > > Client Identifer Spoofing > > By using the agent-supplied Agent Remote ID option, the untrusted > and as-yet unstandardized client identifer field need not be used > by the DHCP server. > > MAC Address Spoofing > > By associating a MAC address with an Agent Remote ID, the DHCP > server can prevent offering an IP address to an attacker spoofing > the same MAC address on a different remote ID. > >5.0 Security Considerations > > DHCP as currently defined provides no authentication or security > mechanisms. Potential exposures to attack are discussed in section 7 > of the DHCP protocol specification in RFC 2131 [1]. > > This document introduces mechanisms to address several security > attacks on the operation of IP address assignment, including IP > spoofing, Client ID spoofing, MAC address spoofing, and DHCP server > address exhaustion. It relies on an implied trusted relationship > between the DHCP Relay Agent and the DHCP server, with an assumed > untrusted DHCP client. It introduces a new identifer, the "Remote > ID", that is also assumed to be trusted. The Remote ID is provided by > the access network or modem and not by client premise equipment. > Cryptographic or other techniques to authenticate the remote ID are > certainly possible and encouraged, but are beyond the scope of this > document. > > > > >Expires October 1999 [Page 12] > > > > > > April 8, 1999 > > > Note that any future mechanisms for authenticating DHCP client to > server communications must take care to omit the DHCP Relay Agent > option from server authentication calculations. This was the > principal reason for organizing the DHCP Relay Agent Option as a > single option with sub-options, and for requiring the relay agent to > remove the option before forwarding to the client. > > While it is beyond the scope of this document to specify the general > forwarding algorithm of public data circuit access units, note that > automatic reforwarding of IP or ARP broadcast packets back downstream > exposes serious IP security risks. For example, if an upstream > broadcast DHCP-DISCOVER or DHCP-REQUEST were re-broadcast back > downstream, any public host may easily spoof the desired DHCP server. > >6.0 IANA Considerations > > IANA is required to maintain a new number space of "DHCP Relay Agent > Sub-options", with the initial sub-options as described in this > document. > > IANA MUST assign future DHCP Relay Agent Sub-options with a "IETF > Consensus" policy as described in RFC 2434 [3]. Future proposed > sub-options MUST be referenced symbolically in the internet-drafts > that describe them, and shall be assigned numeric codes by IANA when > and if the draft is approved by IESG for Proposed Standard RFC > status. > > >7.0 References > > [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, > Bucknell University, March 1997. > > [2] Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor > Extension" RFC 2132. > > [3] Narten,T. and Alvestrand, H. "Guidelines for Writing an > IANA Considerations Section in RFCs", RFC 2434. > > [4] Bradner, S. "Key words for use in RFCs to Indicate Requirement > Levels", RFC 2119. > > >8.0 Glossary > > > > > > > >Expires October 1999 [Page 13] > > > > > > April 8, 1999 > > > > IANA Internet Assigned Numbers Authority > LIS Logical IP Subnet > MAC Message Authentication Code > RAS Remote Access Server > > > > > > > > > > >9.0 Author's Address > > Michael Patrick > Motorola Information Systems Group > 20 Cabot Blvd., MS M4-30 > Mansfield, MA 02048 > > Phone: (508) 261-5707 > Email: mpatrick@dma.isg.mot.com > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires October 1999 [Page 14] > > -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From dhcp-v4@bucknell.edu Tue Apr 13 20:48:54 1999 Received: from marge.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02277 for ; Tue, 13 Apr 1999 20:48:52 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by marge.bucknell.edu (8.9.3/8.9.3) with SMTP id UAA27171; Tue, 13 Apr 1999 20:44:05 -0400 (EDT) Date: Tue, 13 Apr 1999 20:44:05 -0400 (EDT) Message-Id: <199904140008.UAA17569@marge.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: Re: draft-ietf-dhc-dhcp-dns-09.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 message:sent to dhcp-v4@bucknell.edu by KRE@MUNNARI.OZ.AU follows. ------------------------------------------------------------------ Date: Wed, 07 Apr 1999 14:05:40 -0400 From: Mark Stapp Message-ID: <4.0.2.19990406174916.01a64b90@funnel.cisco.com> Apologies for taking so long to reply. | Yes, this was clearly a shortcoming, and there's consensus that I need to | allow for this encoding. I've proposed (in a reply that went to the dhcp | list, and that you probably didn't see) using the next bit in the 'flags' | field as an indicator that the fqdn is DNS-encoded. No, please don't do that. Just decide (the WG decide) whether a simple ascii string (ie: with restrictions on what characters will be allowed, etc) will really be adequate, or not, and define the thing one way. Making this kind of thing optional is just asking for trouble. Just please do define whatever you decide (for a DNS packet encoding you could refer to 1035) - don't just assume that what is intended is obvious. That is, for an ascii encoding, make it clear that dots separate the labels in the FQDN, and indicate whether there is to be any way to include a dot in a label (the DNS allows it, but that doesn't necessarily mean you must). If you decide not to require the FQDN option to actually contain an FQDN, but just its leading part (client: "My host name is "spock" but I don't know what universe I am in...) then you will need to specify some kind of rule for the server to be able to determine what is a FQDN and what is not. If that is to be as simple as "one label, no dots is nota FQDN, anything else is", then say so, and simply restrict it so that the client can't say "my name is spock.enterprise, but I don't know what universe I am in". Write down your assumptions, and try to make sure that you're covering all the cases (by explicitly covering all possibilities, by prohibiting anything but what you want to allow, or by saying "everything else is undefined"). | In that case, would it | be reasonable to allow a host to send a single element or label as an | indication that it knows only the most-specific part of its domain name, | and would like the DHCP server to append the rest? If you're asking me for some reason, yes, sure, I think that would be reasonable (though I don't see how the encoding of the field is relevant to that). Just specify it if this is to be allowed behaviour. | Since the server is going to perform the PTR update, Says who? Maybe no-one is. | and the PTR update needs to know the name that the client is going | to try to add, Why? And if the client is going to add two or three names (perhaps foo.example.tld www.example.tld ftp.example.tld ...) then it would have to supply all of those in the fdqn option (somehow) so the server can stick them all in the PTR record? The name that the client thinks it is called (and wants to be called) need not have any relationship at all with the name that has been assigned to the IP address (by the PTR record). That name should (ideally, and practically because of the way the world currently implements such PTR security as exists) have a DNS entry with an A record that returns the address that was used to construct the PTR record, but there is no requirement that that name be the one the client likes to refer to itself by. | In addition, I can envision a configuration in which the DHCP servers are | configured to perform updates for clients unless the clients ask to perform | the updates themselves. Then the server should do that. If the client hasn't given a name, the server will have to use one of its choosing. If you require the FQDN option to be present, then clients will either send one, with a FQDN in it that they know the server will be unable to update, or they will send one with a random junk name that they don't care about, and take no notice of what the server does with it. (This is those clients whose code base understands the option, but which don't want the server making any DNS updates at all). | In organizations with a mixture of update-capable | and -incapable clients, or during a period of transition after the general | release of updating clients, it would save DHCP and DNS servers work if the | DHCP clients advertised their intentions. Fine, you can explain that, and request that clients co-operate. This isn't a justification for demanding it however. | The other operational case that | motivates this is that of sites which intend to prohibit updates from DHCP | clients. In those sites, servers need to be able to 'override' the client's | offer to perform the A record update, as described in the draft's section | 3.1, last para. Huh? So if your site is such a site, and I bring my laptop and visit, you're planning on having your server tell my client that my client is not permitted to update its name in my zone file? And you think your server is going to be permitted to do that? | Given those three cases, can the specification remain a MUST, or should it | be a SHOULD? I'd not have it a requirement of any kind (a MAY would be right, but makes no sense here - it's an option, clients use it when they want to - that may be most of the time, that's fine, but there's no need for any kind of upper case noise language to require it). However, you don't need my agreement on this - the WG ought to be (and perhaps is, I don't know) discussing the issue, and deciding what is the correct behaviour. I just read the draft and pointed out a few things which looked a bit odd to me. | The 'clean up after yourself' specification is a SHOULD, not a MUST. If | this becomes a MAY, can I at least add a sentence to the effect that | vendors are encouraged to clean up thoroughly? "vendors" is the wrong word, but yes, clients & servers ought clean up exactly as much as their owners want them to do. Mechanisms to do that certainly ought exist in the code, so it can be enabled if desired, but nothing ought be forcing me to make use of those mechanisms. | >What started me wondering, was in attempting to determine whether the | >server could provide any information which would assist the client in | >sending the data for the fqdn option. | | Ah, I think I understand the issue better now. Section 3.3, para. 5 says | that the server MUST reply with a copy of the data the client sent. I'll | revise that to try to allow for the case where the server has more | knowledge about the more-general parts of the DNS domain that the client is | in. No, while that is all fine, it isn't what I was getting at. I'm no DHCP expert, but as I understand it, the general protocol functions as ... client broadcasts DHCPDISCOVER server(s) return DHCPOFFER client picks an offer and sends DHCPREQUEST server sends DHCPACK (in the normal case anyway, and assuming a client starting with no knowledge at all - I know that most for many exchanges, only the latter two packets are actually used). Now, as I understand this FQDN proposal, the FQDN option goes in the DHCPREQUEST packet (and the server returns data about what happened with it in the DHCPACK). What I was wondering was whether the server could (or should perhaps) include in the DHCPOFFER data that the client might use in constructing the FQDN option that it includes in the DHCPREQUEST. If so, it might be worth mentioning that as a possibility in the draft - so servers know it is reasonable to include that data, and clients know what they can do with it (and I'd certainly say "can" not "must"). That's quite different from whether the server can take the FQDN that the client included in its DHCPREQUEST and change it in any way before returning the FQDN option to the client in the DHCPACK (which is another thing which can be done - it just isn't what I was asking about). Now it is entirely possible that you are not understanding what I'm attempting to say because of some lack of knowledge of mine about how either the DHCP protocol works, or about the intent of the FQDN option. If it is the former, I'm not asking that you educate me, that isn't the role of the WG, you could just (collectively) say "he doesn't understand DHCP" and ignore me. That's fine. On the other hand, if I haven't been able to follow the intent of the draft, that might indicate that it needs some aditional clarification. Or third, it may just be that my earlier messages have not been close to clear about what I'm meaning (which would not be unusual for me). kre From dhcp-v4@bucknell.edu Fri Apr 16 10:10:18 1999 Received: from marge.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03114 for ; Fri, 16 Apr 1999 10:10:17 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by marge.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA00237; Fri, 16 Apr 1999 10:01:50 -0400 (EDT) Date: Fri, 16 Apr 1999 10:01:50 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-ietf-dhc-ipv4-autoconfig-04.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 A New 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 : Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network Author(s) : R. Troll Filename : draft-ietf-dhc-ipv4-autoconfig-04.txt Pages : 8 Date : 15-Apr-99 With operating systems appearing in more and more devices, as well as computers appearing in more and more aspects of everyday life, communication between networked devices is increasingly important. The communication mechanism between these devices must be able to not only support the office LAN environment, but must also scale to larger WANS and the internet. This draft describes a method by which a host may automatically give itself a link-local IPv4 address, so that it will be able to use IP applications in the absence of an IP address management mechanism, such as DHCP. This mechanism is in use today by a few operating systems, and additional information on those implementations is also provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-ipv4-autoconfig-04.txt Internet-Drafts are also 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-ipv4-autoconfig-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-ipv4-autoconfig-04.txt". NOTE: The mail server at ietf.org 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. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19990415131705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-ipv4-autoconfig-04.txt From dhcp-v4@bucknell.edu Mon Apr 19 22:26:52 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23224 for ; Mon, 19 Apr 1999 22:26:50 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id WAA24050; Mon, 19 Apr 1999 22:19:46 -0400 (EDT) Date: Mon, 19 Apr 1999 22:19:46 -0400 (EDT) Message-Id: <199904190120.VAA20730@csrlink.net> Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Restarting in INIT-REBOOT state X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 There was some discussion at the last DHC WG meeting in Minneapolis about whether a client should restart in INIT state or INIT-REBOOT state when it has either RELEASEd its previous address or the lease on the address expired while the client was down. The original intent of RFC 2131 was that a client should start in INIT state in both of those cases. However, as an optimization, a client might restart in INIT-REBOOT state and send an initial DHCPREQUEST message in those cases as an optimization; in the case that the client's previous address can be reassigned to the client, the server can respond with a DHCPACK immediately rather than using the four-message INIT state process. The Apple OT 2.02 client restarts in INIT-REBOOT state after sending a DHCPRELEASE during shutdown. Are there other clients in use today that restart in INIT-REBOOT state with an expired or RELEASEd address? It seems to me that allowing clients to restart in INIT-REBOOT state with a remembered but no longer leased address depends on servers responding with a DHCPNAK if the address is, indeed, no longer valid; for example, if the address has been reassigned to another client. But, I read in a discussion about the Apple OT 2.02 client that at least some servers, after receiving a DHCPREQUEST for an expired address, remain silent rather than sending a DHCPNAK. If the servers don't send a DHCPNAK, the restarting client will continue to use its RELEASEd or expired address. Of course, if the address has, indeed, been assigned to another client, there will be two clients using the same IP address. I'd like to hear about servers in use today - how do they respond to a REQUEST for an expired or RELEASEd address? Do they remain silent, always reply with a DHCPNAK or reply with DHCPNAK/DHCPACK depending on whether the REQUESTed address is still available? - Ralph - Ralph Droms Computer Science Department (570) 577-1145 (o) Bucknell University (570) 577-1822 (f) Lewisburg, PA 17837 droms@bucknell.edu From dhcp-v4@bucknell.edu Tue Apr 20 02:49:06 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02698 for ; Tue, 20 Apr 1999 02:49:06 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id CAA13371; Tue, 20 Apr 1999 02:44:19 -0400 (EDT) Date: Tue, 20 Apr 1999 02:44:19 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Ralph E. Droms" To: Multiple recipients of list Subject: Protocol Action: DHCP Options for Service Location Protocol to X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 The IESG has approved the Internet-Draft 'DHCP Options for Service Location Protocol' as a Proposed Standard. This document is the product of the Dynamic Host Configuration Working Group. The IESG contact person is Thomas Narten and Erik Nordmark. Technical Summary The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network. The Service Location Protocol (SLP) provides a default configuration for Scopes and Directory Agents may be discovered using multicast or broadcast. In larger environments, however, it is useful to be able to configure SLP Agents using DHCP, so as to centralize the administration and to deploy SLP in networks where multicast routing is not available. This document defines two new options. The "SLP Directory Agent Option" communicates to clients which Directory Agent(s) they should use. The "SLP Service Scope Option" communicates to clients which scope(s) they should use when using SLP. Working Group Summary The format of the options were changed multiple times over a long period of time in response to specific concerns. In the end, there was consenus on this version of the document. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. From dhcp-v4@bucknell.edu Tue Apr 20 11:57:59 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12211 for ; Tue, 20 Apr 1999 11:57:59 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA23441; Tue, 20 Apr 1999 11:51:08 -0400 (EDT) Date: Tue, 20 Apr 1999 11:51:08 -0400 (EDT) Message-Id: <199904201513.LAA00769@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Restarting in INIT-REBOOT state X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 In order for the optimization you're talking about to work, a client in INIT-REBOOT with a lease that's expired must not use that lease - if it can't contact the server with a broadcast DHCPREQUEST, it has to go back to INIT. With that caveat, I think it works just fine. The ISC DHCP server will respond with a DHCPNAK if a client tries to get an address that's already in use by some other client using a DHCPREQUEST. _MelloN_ From dhcp-v4@bucknell.edu Wed Apr 21 12:42:03 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11003 for ; Wed, 21 Apr 1999 12:42:01 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA27628; Wed, 21 Apr 1999 12:29:02 -0400 (EDT) Date: Wed, 21 Apr 1999 12:29:02 -0400 (EDT) Message-Id: <199904211623.MAA11122@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: Restarting in INIT-REBOOT state X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 At 10:25 PM 4/19/99 -0400, Ralph Droms wrote: >There was some discussion at the last DHC WG meeting in Minneapolis about >whether a client should restart in INIT state or INIT-REBOOT state when it >has either RELEASEd its previous address or the lease on the address >expired while the client was down. The original intent of RFC 2131 was >that a client should start in INIT state in both of those cases. However, >as an optimization, a client might restart in INIT-REBOOT state and send an >initial DHCPREQUEST message in those cases as an optimization; in the case >that the client's previous address can be reassigned to the client, the >server can respond with a DHCPACK immediately rather than using the >four-message INIT state process. One of the reasons this came up was that I was interested in whether people actually implemented the original intent of RFC2131. If they did (or someday could get their implementations compliant with the original intent), then the failover protocol could operate more effectively. Today, the failover protocol assumes that a client has been assigned an IP address and that there is time left to run on the lease if it sees that client RENEW an IP address, but doesn't make that same assumption for an INIT-REBOOT. Were the original intent of RFC 2131 implemented by DHCP clients, then the failover protocol could *also* assume that a client had been assigned an IP address and there there was time left to run on the lease if it sees a client send in an INIT-REBOOT for that IP address. This would allow servers implementing the protocol to provide increased availability in cases where servers were going up and down and the communications path between the servers was intermittent. However, my current belief is that, even given that we clarify the interpretation of RFC 2131 to the original intent (and not change it as an optimization, as it appears you are considering), we're going to have to assume that clients don't do it the "intended" way for at least some years to come. > >The Apple OT 2.02 client restarts in INIT-REBOOT state after sending a >DHCPRELEASE during shutdown. Are there other clients in use today that >restart in INIT-REBOOT state with an expired or RELEASEd address? > >It seems to me that allowing clients to restart in INIT-REBOOT state with a >remembered but no longer leased address depends on servers responding with >a DHCPNAK if the address is, indeed, no longer valid; for example, if the >address has been reassigned to another client. But, I read in a discussion >about the Apple OT 2.02 client that at least some servers, after receiving >a DHCPREQUEST for an expired address, remain silent rather than sending a >DHCPNAK. If the servers don't send a DHCPNAK, the restarting client will >continue to use its RELEASEd or expired address. Of course, if the address >has, indeed, been assigned to another client, there will be two clients >using the same IP address. > >I'd like to hear about servers in use today - how do they respond to a >REQUEST for an expired or RELEASEd address? Do they remain silent, always >reply with a DHCPNAK or reply with DHCPNAK/DHCPACK depending on whether the >REQUESTed address is still available? Our server will always respond to an INIT-REBOOT if the address is managed by our server. It will do the third thing you mentioned above -- if we find the address available, we'll give it to the client (DHCPACCK) despite the client not having sent in a DISCOVER, or if it isn't available, we'll send a DHCPNAK. > >- Ralph >- Ralph Droms > Computer Science Department (570) 577-1145 (o) > Bucknell University (570) 577-1822 (f) > Lewisburg, PA 17837 droms@bucknell.edu > > From dhcp-v4@bucknell.edu Thu Apr 22 13:23:06 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23519 for ; Thu, 22 Apr 1999 13:23:04 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA32026; Thu, 22 Apr 1999 13:16:14 -0400 (EDT) Date: Thu, 22 Apr 1999 13:16:14 -0400 (EDT) Message-Id: <003001be8c25$433cf6e0$9b50fb8d@net-derdmann.corpnorth.baynetworks.com> Errors-To: droms@bucknell.edu Reply-To: derdmann@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "David Erdmann" To: Multiple recipients of list Subject: RE: Restarting in INIT-REBOOT state X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit > Ralph Droms posted: > > > I'd like to hear about servers in use today - how do they respond to a > REQUEST for an expired or RELEASEd address? Do they remain silent, always > reply with a DHCPNAK or reply with DHCPNAK/DHCPACK depending on > whether the REQUESTed address is still available? > Our DHCP server will send out an ACK if we are serving IP address and we have a record of the client having previously had that address. We will send out a NAK if: o the IP requested is not on the subnets we serve o the address requested is not the one we have previously associated with this client, but we have a record of the client. We will send nothing if: o we have no record of this client, as per the RFC: "...If the DHCP server has no record of this client, then it MUST remain silent, and MAY output a warning to the network administrator..." I am a little curious about the following from Ralph's original post: > If the servers don't send a DHCPNAK, the restarting client will >continue to use its RELEASEd or expired address. Of course, if the address >has, indeed, been assigned to another client, there will be two clients >using the same IP address. So are you implying that clients not receiving any NAKs will continue to use their expired address? (Sorry if I misinterpreted this.) I agree with the follow-up from Ted Lemon: >In order for the optimization you're talking about to work, a client >in INIT-REBOOT with a lease that's expired must not use that lease - >if it can't contact the server with a broadcast DHCPREQUEST, it has to >go back to INIT. So if the client receives neither an ACK or NAK it should then go to INIT state. -Dave Dave Erdmann Nortel Networks, NetID Group mailto:derdmann@nortelnetworks.com From dhcp-v4@bucknell.edu Thu Apr 22 13:27:55 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23694 for ; Thu, 22 Apr 1999 13:27:48 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA21153; Thu, 22 Apr 1999 13:23:19 -0400 (EDT) Date: Thu, 22 Apr 1999 13:23:19 -0400 (EDT) Message-Id: <199904211850.OAA00910@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Restarting in INIT-REBOOT state X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Today, the failover protocol assumes that a client has > been assigned an IP address and that there is time left > to run on the lease if it sees that client RENEW an IP > address, but doesn't make that same assumption for an > INIT-REBOOT. Were the original intent of RFC 2131 implemented > by DHCP clients, then the failover protocol could *also* assume > that a client had been assigned an IP address and there there was > time left to run on the lease if it sees a client send in an > INIT-REBOOT for that IP address. This would allow servers > implementing the protocol to provide increased availability in > cases where servers were going up and down and the communications > path between the servers was intermittent. If you made this assumption, wouldn't you be setting yourself up for a nasty denial-of-service attack when some client claimed it had the address but really didn't? _MelloN_ From dhcp-v4@bucknell.edu Thu Apr 22 13:30:36 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23772 for ; Thu, 22 Apr 1999 13:30:19 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA18084; Thu, 22 Apr 1999 13:25:14 -0400 (EDT) Date: Thu, 22 Apr 1999 13:25:14 -0400 (EDT) Message-Id: <199904212113.RAA00410@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Restarting in INIT-REBOOT state X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > DHCP sort of runs on the "honor system" anyway, since anyone can use any IP > address at any time -- either a broken client, a malicious client, or any > user that just hard-codes an IP address into a machine. Right, but in general the failover protocol seems not to make much use of information stored on clients - rather, only what the server knows is really trusted. This represents a major change - you're deciding to trust what the client knows. All it would take would be a broken real-time clock in a client somewhere to cause an IP address conflict if you implement this, whereas if you don't, a bad RTC on a client won't cause any problem. _MelloN_ From dhcp-v4@bucknell.edu Thu Apr 22 13:31:10 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23854 for ; Thu, 22 Apr 1999 13:31:05 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA05695; Thu, 22 Apr 1999 13:26:12 -0400 (EDT) Date: Thu, 22 Apr 1999 13:26:12 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: REMINDER: WG Last Call for "The Subnet Selection Option for X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 REMINDER - WG last call ends 4/23... This is a WG last call for "The Subnet Selection Option for DHCP", . This document has been revised according to the comments from the WG discussion in Minneapolis, 3/99. According to the consensus of the WG, the document is now in WG last call prior to submission for acceptance as a Proposed Standard. Please respond to the mailing list with comments by Friday, 4/23. - Ralph Droms - Ralph Droms Computer Science Department (570) 577-1145 (o) Bucknell University (570) 577-1822 (f) Lewisburg, PA 17837 droms@bucknell.edu From dhcp-v4@bucknell.edu Thu Apr 22 13:31:22 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23866 for ; Thu, 22 Apr 1999 13:31:20 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA09257; Thu, 22 Apr 1999 13:24:18 -0400 (EDT) Date: Thu, 22 Apr 1999 13:24:18 -0400 (EDT) Message-Id: <199904211959.PAA20554@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: Restarting in INIT-REBOOT state X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Ted, I'm not sure of the intent of your question. DHCP sort of runs on the "honor system" anyway, since anyone can use any IP address at any time -- either a broken client, a malicious client, or any user that just hard-codes an IP address into a machine. Given that, the failover protocol assumes that anyone sending in a DHCPRENEW or DHCPREBINDING (which, remember are unicast from the IP address which the client is attempting to renew) is the legitimate owner of the IP address -- unless there is other information known to conflict with that assumption. And the ACK is unicast back to the IP address which was just renewed. At present, the same assumption is *not* made about INIT-REBOOT, since I was unaware of the intent of the RFC, and I assumed that clients would send in an INIT-REBOOT whether or not they believed that they had time to run on their leases or not. I was thrown off by the (completely appropriate) use of requested-address option to specify the IP address instead of the ciaddr, since I had internalized the use of ciaddr to mean "I own this address" and the use of the requested-address option to mean "I would like to own this address". In this case, though, there is no choice but to use the requested-address option, since the IP address may well not be legal on this network (the discovery of which is the prinicipal reason for the INIT-REBOOT in the first place). All that said, you can build quite a number of denial of service attacks with DHCP -- you can mimic lots of different clients and do real discovers and get offers and do requests and get acks. You can also send in a renew to many servers today and get them to give you an address w/out going through all of the discover handshake, though this is harder since you actually have to be using the address to get the ack back (but maybe you don't care). You can do the same thing to a failover server, and it will ack in pretty much the same way -- and if you can find two failover server that are partitioned, you can do renews to each of them with different IP addresses and the same client-id and thus construct a duplicate IP address scenario "by hand". So, when (as you put it) "some client claims it has the address but really doesn't", you may well open youself to attack -- but you are already open to much easier attacks of exactly the same sort -- or so they seem to me. Perhaps if you want to pursue this, an example might help me understand your specific concern. Cheers -- Kim At 02:50 PM 4/21/99 -0400, Ted Lemon wrote: > >> Today, the failover protocol assumes that a client has >> been assigned an IP address and that there is time left >> to run on the lease if it sees that client RENEW an IP >> address, but doesn't make that same assumption for an >> INIT-REBOOT. Were the original intent of RFC 2131 implemented >> by DHCP clients, then the failover protocol could *also* assume >> that a client had been assigned an IP address and there there was >> time left to run on the lease if it sees a client send in an >> INIT-REBOOT for that IP address. This would allow servers >> implementing the protocol to provide increased availability in >> cases where servers were going up and down and the communications >> path between the servers was intermittent. > >If you made this assumption, wouldn't you be setting yourself up for a >nasty denial-of-service attack when some client claimed it had the >address but really didn't? > > _MelloN_ > From dhcp-v4@bucknell.edu Thu Apr 22 13:33:28 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23947 for ; Thu, 22 Apr 1999 13:33:25 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA28434; Thu, 22 Apr 1999 13:27:08 -0400 (EDT) Date: Thu, 22 Apr 1999 13:27:08 -0400 (EDT) Message-Id: <199904221428.KAA16779@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: Restarting in INIT-REBOOT state X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 >> Kim said: >> >> DHCP sort of runs on the "honor system" anyway, since anyone can use any IP >> address at any time -- either a broken client, a malicious client, or any >> user that just hard-codes an IP address into a machine. > > Ted replied: > >Right, but in general the failover protocol seems not to make much use >of information stored on clients - rather, only what the server knows >is really trusted. Kim responds: Actually, this isn't how I have conceptualized our approach, although you may well see it differently. First, let me state that I don't expect to change the failover protocol to assume that a client that does an INIT-REBOOT has time left on their lease. Someday I would like to, but that day is probably years in the future. That said, let me try to explain why I disagree with your statement that "only what the server knows is really trusted in the failover protocol". Certainly, if information that the server has and the client has conflict, the server will trust its own information. However, information stored on the client *is* trusted to some degree, and it is what makes the lazy update work. Here is an example... Server A issues an ACK to client X for IP address i.j.k.l, and then queues the binding update to server B (its secondary). However, server A crashes prior to the binding update ever getting sent to server B. Now, server B knows nothing about the fact that client X has IP address i.j.k.l. Client X will try to renew from server A several times, and get no response, and ultimately will do a rebinding (broadcast), and server B will see it. Now, server B will ACK the rebinding from client X for IP address i.j.k.l, even though server B has absolutely *no* record of client X ever using IP address i.j.k.l. However, server B has no conflicting information about some other client using IP address i.j.k.l, and so will assume that, since client X is using the IP address now (and clearly believes that it has time left to run on its lease, or it wouldn't be using it at all), that client X must have been given IP address i.j.k.l by the other server. As an aside, this is why one failover server cannot reallocate an IP address from one client to another client without interlocking with the other server (unless it is in partner-down state, where it has been assured that no other server is operating or can operate without resynchronizing with it). The example above is not the only situation in the failover protocol where information stored on a client is used to allow the protocol to operate, but it is perhaps the simplest and the most likely situation to occur. >This represents a major change - you're deciding >to trust what the client knows. All it would take would be a broken >real-time clock in a client somewhere to cause an IP address conflict >if you implement this, whereas if you don't, a bad RTC on a client >won't cause any problem. Actually, in DHCP a bad RTC on a client (if it is bad in the "correct" way) can easily cause an IP address conflict with or without the failover protocol in operation. DHCP as a service depends on reasonably accurate RTC's in clients (and usually supports a grace period to allow for clocks that aren't too terribly accurate). Any client with an RTC that doesn't run at all, or runs at some significant percentage less than accurate time (say 50% of real time), will cause an IP address conflict today without any interaction with the failover protocol. Cheers -- Kim > > _MelloN_ > From dhcp-v4@bucknell.edu Thu Apr 22 13:34:11 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23994 for ; Thu, 22 Apr 1999 13:34:09 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA18527; Thu, 22 Apr 1999 13:28:10 -0400 (EDT) Date: Thu, 22 Apr 1999 13:28:10 -0400 (EDT) Message-Id: <199904221524.LAA19500@cichlid.raleigh.ibm.com> Errors-To: droms@bucknell.edu Reply-To: narten@raleigh.ibm.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Thomas Narten To: Multiple recipients of list Subject: Re: REMINDER: WG Last Call for "The Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > This is a WG last call for "The Subnet Selection Option for DHCP", > . This document has been revised > according to the comments from the WG discussion in Minneapolis, 3/99. > According to the consensus of the WG, the document is now in WG last call > prior to submission for acceptance as a Proposed Standard. I have to admit that I still don't fully understand what this option will be used for and in what scenario (e.g., I don't quite follow the "control plane" vs. "switching plane" terminology). It would help if the draft gave a concrete example environment where it is needed. Also, who adds this field? Is it the client or the relay agent? If the latter, should this be a normal DHCP option or a relay agent option? Thomas From dhcp-v4@bucknell.edu Mon Apr 26 09:38:53 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17178 for ; Mon, 26 Apr 1999 09:38:52 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA01535; Mon, 26 Apr 1999 09:29:07 -0400 (EDT) Date: Mon, 26 Apr 1999 09:29:07 -0400 (EDT) Message-Id: <21839C593E75D211BF7800805FCCD0264B07E8@msgsrv03.srv.PacBell.COM> Errors-To: droms@bucknell.edu Reply-To: RBHIBBS@msg.pacbell.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "HIBBS, BARR (PB)" To: Multiple recipients of list Subject: RE: REMINDER: WG Last Call for "The Subnet Selection Option for X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 Glenn, Ralph, Thomas, et al.-- 1. Some annoying grammatical errors appear in section 1, "Introduction," that confuse the purpose of the proposed option. The phrases "... specifies the subnet on which a DHCP server should use ..." and "... determine the subnet on which to select an address." should be reworded to avoid this confusion. 2. I also agree with Thomas that the introduction of the concept of a "control" and "packet-handling" plane also serves to confuse the purpose and use of this option. I have no idea what the concept is attempting to accomplish after several readings. 3. When I first read the draft, I thought it was a straightforward option by which (a) a client connected to a network segment consisting of multiple subnets (for example, 129.245.139.0 and 129.245.197.0) might indicate the preferred subnet from which to obtain an address, or (b) a user or vendor-class identifier might specify the subnet for use by members of the class. Now, however, I don't see what problem the draft is attempting to solve nor how it can be used in practice: a client could inadvertently request a subnet using this option that is unreachable from its network connection, but "... the server MUST NOT offer an address that is not on the requested subnet or network segment." Unlike the requested IP address option, this one gives the server no room to offer an address to the client if the client has made an inadvertent mistake. Glenn--I know that you feel this option solves a particular problem that has arisen from your clients or for some planned product offering, but I don't understand it's usefulness. It almost seems as if you believe that the client has better knowledge of the network topology in some circumstances than the network (server) administrator, else why request a specific subnet? When I thought about a network device such as a switch or router that might be connected to two or more different network segments, then I could understand why such a device, as a client [an embedded SNMP agent, perhaps?] might wish to obtain its operating parameters (including IP address) from one network segment in preference to another, but I must say that the draft didn't make the point at all obvious. --Barr From dhcp-v4@bucknell.edu Mon Apr 26 09:43:33 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17237 for ; Mon, 26 Apr 1999 09:43:33 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA03862; Mon, 26 Apr 1999 09:35:46 -0400 (EDT) Date: Mon, 26 Apr 1999 09:35:46 -0400 (EDT) Message-Id: <4.1.19990425062028.0098a250@mail.join.com> Errors-To: droms@bucknell.edu Reply-To: robs@join.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Rob Stevens To: Multiple recipients of list Subject: Re: Restarting in INIT-REBOOT state X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 It seems to me that the clear intent of the RFCs was the clients cannot start in INIT-REBOOT when a) the lease has expired b) the lease was RELEASED It may very well be that this would save 2 packet exchanges in the case where servers have not re-allocated the address; but it will create 2 more packets (REQUEST; NAK; DISCOVER; OFFER; etc) when the servers have re-allocated the address. The gain in efficiency is thus diminished. I would like to make this a MUST NOT (ie if either of the two conditions holds, client MUST NOT start in INIT_REBOOT). Nonetheless we support such clients and don't pedantically NAK if no other ill-effect would occur: a) If the client is on a subnet not served - remain silent (perhaps should NAK if IP address inconsistent with net, but if subnet not served, the server may not have the proper masking/logical net configuration available) b) If the IP address is bound to another client: NAK c) If the client is already bound to a different IP address: NAK d) If the IP address is not one adminstered by he server: remain silent e) If the IP address is still bound to the client (whether expired or no) ACK (and update lease expiration to new value). Rob From dhcp-v4@bucknell.edu Mon Apr 26 14:02:57 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20655 for ; Mon, 26 Apr 1999 14:02:56 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA22510; Mon, 26 Apr 1999 13:55:14 -0400 (EDT) Date: Mon, 26 Apr 1999 13:55:14 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dbabbitt@austin.ibm.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: David Babbitt To: Multiple recipients of list Subject: Re: Restarting in INIT-REBOOT state X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 > a) If the client is on a subnet not served - remain silent > (perhaps should NAK if IP address inconsistent with net, > but if subnet not served, the server may not have the > proper masking/logical net configuration available) > b) If the IP address is bound to another client: NAK > c) If the client is already bound to a different IP address: NAK > d) If the IP address is not one adminstered by the server: remain silent > e) If the IP address is still bound to the client (whether expired or no) > ACK (and update lease expiration to new value). Our server (AIX) is about identical to this behavior. I'd like to raise another question about steps (a) and (d) here. I contend that the server should remain silent in both of these cases because it can't be positive that it's the only server on the network or the only server servicing the subnet in question. More specifically, in (a), I wouldn't want the server to NAK when it thinks that the subnet doesn't match the address if there exists another server on the network that is configured for multiple subnets on that physical network. The reason I bring this is up is to find out about the behavior of other vendors' DHCP clients. I've had to argue the behavior of my server concerning the above with customers after they realized that some clients will continue to use their previous lease when neither an ACK nor a NAK is received in the INIT-REBOOT state. E.g., a laptop moves from one subnet to another, the new subnet isn't controlled by the old server, and therefore the client falls into scenario (a), gets no response, but continues with the old address ... Thanks, David From dhcp-v4@bucknell.edu Mon Apr 26 14:03:01 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20666 for ; Mon, 26 Apr 1999 14:03:00 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA21896; Mon, 26 Apr 1999 13:57:53 -0400 (EDT) Date: Mon, 26 Apr 1999 13:57:53 -0400 (EDT) Message-Id: <199904261435.KAA16582@cichlid.raleigh.ibm.com> Errors-To: droms@bucknell.edu Reply-To: narten@raleigh.ibm.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Thomas Narten To: Multiple recipients of list Subject: Re: REMINDER: WG Last Call for "The Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 "Glenn Waters" writes: > > I have to admit that I still don't fully understand what this option > > will be used for and in what scenario (e.g., I don't quite follow the > > "control plane" vs. "switching plane" terminology). It would help if > > the draft gave a concrete example environment where it is needed. > an example of such an environment is a RAS device that allocates addresses > on behalf of its RAS clients. furthermore, the RAS clients are on subnet(s) > that are not network connected (routed or direct) to the subnet that the > dhcp server is on. however, at least one subnet on the RAS device is > network connected to the dhcp server for the purposes of allocating > addresses. the "switching plane" are the subnets that the RAS clients > connect to. the "control plane" is the subnet(s) that are network connected > to the dhcp server. OK. I think I get it. The "client" isn't really what we normally think of as the client (i.e, the entity actually formulating the request). That is, the actual end-point client may be running PPP to the RAS, and the RAS wants addresses to send over the PPP link using the PPP negotiation mechanism. Is this the scenario? Also, is the reason there is no network connectivity between the end-client and the DHCP server due to policy? Seems like there would be sufficient connectivity. I.e., a layer-2 connection to the RAS server, than layer 3 to the DHCP server. But this is precisely the case that DHCP would seem to already handle. Also, how many addresses can the same "client" request? I.e, if the RAS makes a dozen requests over a period of time, how are those allocations distinguished? Is it assumed that the DHCP "client" (i.e., the RAS not the end-client) uses a differnet client ID and/or MAC addresses? Some text on this point would probably be useful to have in the draft. Finally, one other point. The option itself encodes a "subnet" as a 4-byte field. Seems to me like you need to include the network mask. One can't reliably extract a subnet number of an address just by looking at it in the general case. Thomas From dhcp-v4@bucknell.edu Mon Apr 26 14:03:25 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20678 for ; Mon, 26 Apr 1999 14:03:24 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA23861; Mon, 26 Apr 1999 13:58:45 -0400 (EDT) Date: Mon, 26 Apr 1999 13:58:45 -0400 (EDT) Message-Id: <002d01be8ff7$793fa1e0$8a50fb8d@corpnorth.baynetworks.com> Errors-To: droms@bucknell.edu Reply-To: gww@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Glenn Waters" To: Multiple recipients of list Subject: RE: REMINDER: WG Last Call for "The Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Thomas Narten [mailto:narten@raleigh.ibm.com] > Sent: Monday, April 26, 1999 10:35 > To: Glenn Waters > Cc: Multiple recipients of list > Subject: Re: REMINDER: WG Last Call for "The Subnet Selection Option for > DHCP" > > > "Glenn Waters" writes: > > > > I have to admit that I still don't fully understand what this option > > > will be used for and in what scenario (e.g., I don't quite follow the > > > "control plane" vs. "switching plane" terminology). It would help if > > > the draft gave a concrete example environment where it is needed. > > > an example of such an environment is a RAS device that > allocates addresses > > on behalf of its RAS clients. furthermore, the RAS clients are > on subnet(s) > > that are not network connected (routed or direct) to the subnet that the > > dhcp server is on. however, at least one subnet on the RAS device is > > network connected to the dhcp server for the purposes of allocating > > addresses. the "switching plane" are the subnets that the RAS clients > > connect to. the "control plane" is the subnet(s) that are > network connected > > to the dhcp server. > > OK. I think I get it. The "client" isn't really what we normally think > of as the client (i.e, the entity actually formulating the > request). That is, the actual end-point client may be running PPP to > the RAS, and the RAS wants addresses to send over the PPP link using > the PPP negotiation mechanism. Is this the scenario? yes, this is the scenario. > Also, is the reason there is no network connectivity between the > end-client and the DHCP server due to policy? Seems like there would > be sufficient connectivity. I.e., a layer-2 connection to the RAS > server, than layer 3 to the DHCP server. But this is precisely the > case that DHCP would seem to already handle. it is due to security (which is policy, but then again what isn't policy these days in the IETF :). there is not sufficient connectivy in that there does not exist any routed network connectivity to the "RAS" subnets to/from the DHCP server. there is routed connectivity to the control plane portion of the box. the scenario where the RAS subnets cannot route to the subnet of the DHCP server is in a ISP outsourcing environment where you do not want customers having any type of access to the ISP's internal network. > Also, how many addresses can the same "client" request? I.e, if the > RAS makes a dozen requests over a period of time, how are those > allocations distinguished? Is it assumed that the DHCP "client" (i.e., > the RAS not the end-client) uses a differnet client ID and/or MAC > addresses? Some text on this point would probably be useful to have in > the draft. i could add this text if you feel it is really neccessary. i am reluctant to do so since the text really is describing how to do proxy dhcp services and that is not the main point of this draft. > Finally, one other point. The option itself encodes a "subnet" as a > 4-byte field. Seems to me like you need to include the network > mask. One can't reliably extract a subnet number of an address just by > looking at it in the general case. dhcp servers know how to take an address without a mask and determine the subnet for that address. they can do this because the contain the topology on the relevant pieces of the network. dhcp servers must deal with the giaddr field in exactly the same way as they must do so for this option. > Thomas thanks for you comments. i can add the RAS example to the text of the draft. i can change the terms "control" and "switching" plane but would like some suggestions (not neccessarily just from thomas) on some new terms. /gww From dhcp-v4@bucknell.edu Mon Apr 26 17:56:44 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24609 for ; Mon, 26 Apr 1999 17:56:43 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA04240; Mon, 26 Apr 1999 17:50:56 -0400 (EDT) Date: Mon, 26 Apr 1999 17:50:56 -0400 (EDT) Message-Id: <199904261825.OAA11690@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: REMINDER: WG Last Call for "The Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Finally, one other point. The option itself encodes a "subnet" as a > 4-byte field. Seems to me like you need to include the network > mask. One can't reliably extract a subnet number of an address just by > looking at it in the general case. That's what we do now! This has to be dealt with by configuring the server to know the layout, including subnet masks, of the networks it's serving. I don't think this adds value - in reality it's going to make the server's job harder, not easier, since the server will then have to implement a different code path to use the subnet selection option than it now uses to support the giaddr. _MelloN_ From dhcp-v4@bucknell.edu Mon Apr 26 17:57:26 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24625 for ; Mon, 26 Apr 1999 17:57:25 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA01546; Mon, 26 Apr 1999 17:53:03 -0400 (EDT) Date: Mon, 26 Apr 1999 17:53:03 -0400 (EDT) Message-Id: <199904261849.OAA11765@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Restarting in INIT-REBOOT state X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > > a) If the client is on a subnet not served - remain silent > > (perhaps should NAK if IP address inconsistent with net, > > but if subnet not served, the server may not have the > > proper masking/logical net configuration available) > > d) If the IP address is not one adminstered by the server: remain silent > I contend that the server should remain silent in both of these > cases because it can't be positive that it's the only server on > the network or the only server servicing the subnet in question. > More specifically, in (a), I wouldn't want the server to NAK > when it thinks that the subnet doesn't match the address if > there exists another server on the network that is configured for > multiple subnets on that physical network. This seems correct to me too. > I've had to argue the behavior of my server concerning the above > with customers after they realized that some clients will continue > to use their previous lease when neither an ACK nor a NAK is received > in the INIT-REBOOT state. E.g., a laptop moves from one subnet to another, > the new subnet isn't controlled by the old server, and therefore > the client falls into scenario (a), gets no response, but continues > with the old address ... This shouldn't happen if there's a DHCP server on the new net. In (d), the server SHOULD NAK if the IP address is on the wrong network, even if it doesn't have any record of the IP address. This is how version 2.0 of the ISC DHCP server behaves by default. In version 3, because so many people are setting up DHCP servers at home connected to cable modem services, I've set the default so that it won't NAK unless it has a record of the address, but in any real production environment this is incorrect - the server administrator should configure it with correct knowledge of the network, and it should always NAK requests for IP addresses that aren't valid for the network they originated on. _MelloN_ From dhcp-v4@bucknell.edu Mon Apr 26 22:19:10 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26285 for ; Mon, 26 Apr 1999 22:19:09 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id WAA19919; Mon, 26 Apr 1999 22:14:01 -0400 (EDT) Date: Mon, 26 Apr 1999 22:14:01 -0400 (EDT) Message-Id: <21839C593E75D211BF7800805FCCD0264B07EA@msgsrv03.srv.PacBell.COM> Errors-To: droms@bucknell.edu Reply-To: RBHIBBS@msg.pacbell.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "HIBBS, BARR (PB)" To: Multiple recipients of list Subject: RE: REMINDER: WG Last Call for "The Subnet Selection Option for D X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 Ted, Thomas, Glenn, et al.-- Ted, I wasn't sure if you were agreeing or disagreeing with Thomas about the need for a subnet mask. I don't agree that including the subnet mask necessarily makes the server implementation more difficult, although I also don't think it is really required: as you point out, all current servers must somehow do without the subnet mask when processing giaddr to determine the subnet where the response is to be returned. What is pretty clear to me is that if the subnet mask declared in the server's configuration doesn't match the one provided by the client (if Thomas' suggestion is adopted) at the very least there will be some confusion, and at worst an address won't be served. Having multiple sources for the same information opens the possibility of contradictory configurations which could introduce subtle operating problems. --Barr > ---------- > From: Ted Lemon[SMTP:mellon@isc.org] > Sent: Monday, April 26, 1999 2:51 PM > > > Finally, one other point. The option itself encodes a "subnet" as a > > 4-byte field. Seems to me like you need to include the network > > mask. One can't reliably extract a subnet number of an address just by > > looking at it in the general case. > > That's what we do now! This has to be dealt with by configuring the > server to know the layout, including subnet masks, of the networks > it's serving. I don't think this adds value - in reality it's going > to make the server's job harder, not easier, since the server will > then have to implement a different code path to use the subnet > selection option than it now uses to support the giaddr. > > From dhcp-v4@bucknell.edu Tue Apr 27 00:15:17 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29069 for ; Tue, 27 Apr 1999 00:15:16 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA02132; Tue, 27 Apr 1999 00:10:36 -0400 (EDT) Date: Tue, 27 Apr 1999 00:10:36 -0400 (EDT) Message-Id: <199904270226.WAA13221@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: REMINDER: WG Last Call for "The Subnet Selection Option for D X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > I wasn't sure if you were agreeing or disagreeing with Thomas about the need > for a subnet mask. No, I was disagreeing strongly. "I don't wanna hafta implement that!" _MelloN_ From dhcp-v4@bucknell.edu Tue Apr 27 08:48:33 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08955 for ; Tue, 27 Apr 1999 08:48:33 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA30528; Tue, 27 Apr 1999 08:41:38 -0400 (EDT) Date: Tue, 27 Apr 1999 08:41:38 -0400 (EDT) Message-Id: <199904271212.IAA01952@hygro.adsl.duke.edu> Errors-To: droms@bucknell.edu Reply-To: narten@raleigh.ibm.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Thomas Narten To: Multiple recipients of list Subject: Re: REMINDER: WG Last Call for "The Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Ted Lemon writes: > > Finally, one other point. The option itself encodes a "subnet" as a > > 4-byte field. Seems to me like you need to include the network > > mask. One can't reliably extract a subnet number of an address just by > > looking at it in the general case. > That's what we do now! This has to be dealt with by configuring the > server to know the layout, including subnet masks, of the networks > it's serving. I don't think this adds value - in reality it's going > to make the server's job harder, not easier, since the server will > then have to implement a different code path to use the subnet > selection option than it now uses to support the giaddr. Understood. I withdraw my suggestion. Question: in the DHCP v6 discussions, at one point there was discussion about putting the subnet mask (together with the relay agent address) into DHCP packets so that the server would NOT need have have explicit configuration knowledge of which subnet a relay agent (and client) was on (i.e., the configuration information alluded to above). The idea was that the DHCP packets would contain sufficient information for the server to figure out which link the client is on. This would presumably simplify configuration of servers. Does the above actually make sense? Would this be a desirable feature to have, or does it not really buy much operationally when looking at the big picture? Thomas From dhcp-v4@bucknell.edu Tue Apr 27 12:08:23 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18911 for ; Tue, 27 Apr 1999 12:08:23 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA22611; Tue, 27 Apr 1999 11:57:16 -0400 (EDT) Date: Tue, 27 Apr 1999 11:57:16 -0400 (EDT) Message-Id: <63D30D6E10CFD11190A90000F805FE860116789F@lespaul.process.com> Errors-To: droms@bucknell.edu Reply-To: Bennett@process.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Andy Bennett To: Multiple recipients of list Subject: Mailing list for DHCP Schema for LDAP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.0.1460.8) Mime-Version: 1.0 We've created a mailing list for discussion of a draft to define an LDAP Schema for DHCP configuration information. At this point the draft is more of a work in progress which is why the discussions are not taking place on the dhcp-v4 list. If you would like to participate, you can join the mailing list by sending a message to: dhcp-schema-request@lists.process.com In the body of the message, include a command of the form: SUBSCRIBE "username" (or just "SUBSCRIBE") If you want to remove yourself from the list, you can send a message to: dhcp-schema-request@lists.process.com In the body of the message, include the command "SIGNOFF". To send a message to the list, send your message to: "dhcp-schema@lists.process.com" Note that only members of the list can submit messages to this mailing list. If you'd like to review the current status of this work, it is described at: http://www.process.com/schemas/schema.htm If you'd like to view the latest draft, it is available at: http::/www.process.com/schemas/draftschema.html If you have problems getting any of this to work, let me know. Thanks, Andy Bennett Process Software bennett@process.com From dhcp-v4@bucknell.edu Tue Apr 27 12:09:00 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18939 for ; Tue, 27 Apr 1999 12:08:59 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA21814; Tue, 27 Apr 1999 11:59:38 -0400 (EDT) Date: Tue, 27 Apr 1999 11:59:38 -0400 (EDT) Message-Id: <199904271454.KAA15880@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: REMINDER: WG Last Call for "The Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Question: in the DHCP v6 discussions, at one point there was > discussion about putting the subnet mask (together with the relay > agent address) into DHCP packets so that the server would NOT need > have have explicit configuration knowledge of which subnet a relay > agent (and client) was on (i.e., the configuration information alluded > to above). The idea was that the DHCP packets would contain sufficient > information for the server to figure out which link the client is > on. This would presumably simplify configuration of servers. I don't know enough about DHCPv6 in particular to be sure, but my inclination is to say that this is also a bad idea. The DHCP server administrator has to configure the DHCP server with addresses to assign. If there's any repository of the true state of the network, it's going to be on the DHCP server (unless you also hack the relay agent to include information about its secondary IP addresses in each packet). Pushing the configured state from the network *away* from the central server seems to me like the opposite of what should be done. If the DHCP server could somehow automatically configure itself without any operator intervention, maybe this would make sense, but I don't think it can, and I think that just including the subnet mask in the relayed packet doesn't make this any more possible. _MelloN_ From dhcp-v4@bucknell.edu Tue Apr 27 13:47:54 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24931 for ; Tue, 27 Apr 1999 13:47:50 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA22438; Tue, 27 Apr 1999 13:38:11 -0400 (EDT) Date: Tue, 27 Apr 1999 13:38:11 -0400 (EDT) Message-Id: <199904271700.NAA22148@cichlid.raleigh.ibm.com> Errors-To: droms@bucknell.edu Reply-To: narten@raleigh.ibm.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Thomas Narten To: Multiple recipients of list Subject: Re: REMINDER: WG Last Call for "The Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > > Also, is the reason there is no network connectivity between the > > end-client and the DHCP server due to policy? Seems like there would > > be sufficient connectivity. I.e., a layer-2 connection to the RAS > > server, than layer 3 to the DHCP server. But this is precisely the > > case that DHCP would seem to already handle. > it is due to security (which is policy, but then again what isn't policy > these days in the IETF :). there is not sufficient connectivy in that there > does not exist any routed network connectivity to the "RAS" subnets to/from > the DHCP server. there is routed connectivity to the control plane portion > of the box. the scenario where the RAS subnets cannot route to the subnet > of the DHCP server is in a ISP outsourcing environment where you do not want > customers having any type of access to the ISP's internal network. Seems to me like we're splitting hairs here. One can have filters that allow only DHCP packets to be relayed by the RAS and satisfy security concerns. I.e., the RAS is a relay agent. If your security policy doesn't like that model, should the DHCP protocol be bent to get around management dictates? > > Also, how many addresses can the same "client" request? I.e, if the > > RAS makes a dozen requests over a period of time, how are those > > allocations distinguished? Is it assumed that the DHCP "client" (i.e., > > the RAS not the end-client) uses a differnet client ID and/or MAC > > addresses? Some text on this point would probably be useful to have in > > the draft. > i could add this text if you feel it is really neccessary. i am reluctant > to do so since the text really is describing how to do proxy dhcp services > and that is not the main point of this draft. Seems to me that this draft takes a very definite stand in support of a proxy DHCP service. I believe this is the first document to do so. I think it would be good for the WG to think hard about whether it wants to support this and to what degree. I'm not saying it shouldn't, just that the WG should not blindly go forward without thinking through the longer-term implications. I.e., will there be more options needed in the future? Will the RAS want to ask for a block of addresses rather than just one? Thomas From dhcp-v4@bucknell.edu Tue Apr 27 13:53:51 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25253 for ; Tue, 27 Apr 1999 13:53:50 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA17786; Tue, 27 Apr 1999 13:40:07 -0400 (EDT) Date: Tue, 27 Apr 1999 13:40:07 -0400 (EDT) Message-Id: <001901be90d3$070e9d10$8a50fb8d@corpnorth.baynetworks.com> Errors-To: droms@bucknell.edu Reply-To: gww@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Glenn Waters" To: Multiple recipients of list Subject: RE: REMINDER: WG Last Call for "The Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit > Seems to me that this draft takes a very definite stand in support of > a proxy DHCP service. I believe this is the first document to do so. i am still reluctant to add anything about proxy service except possibly in the context of an example. the example could restate the dhcp requirement about using a unique client-id for each address that is to be proxied. i do not want to state anything to formally since RFC2131 is quite clear on how a server is to hand out addresses and none of that logic in RFC2131 changes as a result of this document. > think it would be good for the WG to think hard about whether it wants > to support this and to what degree. I'm not saying it shouldn't, just > that the WG should not blindly go forward without thinking through the > longer-term implications. I.e., will there be more options needed in > the future? i presented this draft to the WG in minneapolis and there was support from most of the major dhcp vendors. i thus believe that the WG wants to support this effort, however that is just my opinion. > Will the RAS want to ask for a block of addresses rather > than just one? RAS's currently do ask for a block of addresses -- one at a time. each address request must contain a unique client-id. > Thomas cheers, /gww From dhcp-v4@bucknell.edu Tue Apr 27 19:16:25 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02441 for ; Tue, 27 Apr 1999 19:16:24 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA26884; Tue, 27 Apr 1999 19:11:08 -0400 (EDT) Date: Tue, 27 Apr 1999 19:11:08 -0400 (EDT) Message-Id: <000101be90ff$bc506c40$0a01a8c0@nemesis2> Errors-To: droms@bucknell.edu Reply-To: william@tdce.com.au Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "William Bartholomew" To: Multiple recipients of list Subject: RE: REMINDER: WG Last Call for "The Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit It is my opinion that ANY feature that simplify the use of DHCP across multiple subnets is going to be of great benefit to the Internet community. This is because subnetting is becomming a more and more common practice even in smaller networks simply because it allows the company/organisation/individual to enhance security or efficiency of their network. So if DHCP changes to allow ease of configuration in multiple subnets, or to enhance communication between DHCP servers then this will be of great benefit to smaller organisations that need the power of subnetting but need flexibility and ease of management... What other ways are there to make DHCP servers easier to manage in a smaller yet complex environment???? Regards, William D. Batholomew MCP MCSE CNA Nemesis Software International wbartholomew@nemesissoft.com.au (0418)199-661 Suite 175, 4/58 High Street Toowong, QLD 4066 AUSTRALIA From dhcp-v4@bucknell.edu Tue Apr 27 20:47:17 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03034 for ; Tue, 27 Apr 1999 20:47:15 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id UAA15997; Tue, 27 Apr 1999 20:42:20 -0400 (EDT) Date: Tue, 27 Apr 1999 20:42:20 -0400 (EDT) Message-Id: <199904280013.UAA17409@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: REMINDER: WG Last Call for "The Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > i presented this draft to the WG in minneapolis and there was support from > most of the major dhcp vendors. i thus believe that the WG wants to support > this effort, however that is just my opinion. I think your impression was right. I can think of some uses for this option as well, and I'm very interested in implementing it. > RAS's currently do ask for a block of addresses -- one at a time. each > address request must contain a unique client-id. Right, without seriously hacking the protocol, getting blocks of addresses would be a pain. _MelloN_ From dhcp-v4@bucknell.edu Fri Apr 30 16:43:39 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12343 for ; Fri, 30 Apr 1999 16:43:38 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA00302; Fri, 30 Apr 1999 16:37:54 -0400 (EDT) Date: Fri, 30 Apr 1999 16:37:54 -0400 (EDT) Message-Id: <003301be934c$f4dbddc0$40fb94d0@megalink.net> Errors-To: droms@bucknell.edu Reply-To: jwgreene@megalink.net Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Jim Greene" To: Multiple recipients of list Subject: dhcp + Authentication X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook Express 5.00.2014.211 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Hello Group... I have a question regarding the use of DHCP and authentication. Is there a way to make the client provide authentication information before dhcpd will give the client an IP address. Is there other ways to go about this. I know Road Runner and others do this. DO you have any idea how it is done ?. From reading over the dhcp RFC's there is nothing built in that I can see. ANy help would be appreciated A LOT Thanks Jim G From dhcp-v4@bucknell.edu Fri Apr 30 17:35:27 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13097 for ; Fri, 30 Apr 1999 17:35:26 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA23472; Fri, 30 Apr 1999 17:29:37 -0400 (EDT) Date: Fri, 30 Apr 1999 17:29:37 -0400 (EDT) Message-Id: <000d01be935d$a0a8a100$1a4957cf@bill-moore> Errors-To: droms@bucknell.edu Reply-To: bmoore@nts.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Bill Moore" To: Multiple recipients of list Subject: RE: dhcp + Authentication X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit DHCP + Authentication = PPP over Ethernet Well, not exactly. But some of the big DSL and cable modem service providers are looking to PPP over Ethernet as a better alternative to DHCP for dynamic configuration and authentication. PPP over Ethernet and uses existing RADIUS-based billing and provisioning systems. http://www.nts.com/library/tlpppoe.html Bill Moore NTS http://www.nts.com > -----Original Message----- > From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu]On Behalf Of Jim > Greene > Sent: Friday, April 30, 1999 1:41 PM > To: Multiple recipients of list > Subject: dhcp + Authentication > > > Hello Group... > I have a question regarding the use of DHCP and authentication. > Is there a way to make the client provide authentication > information before > dhcpd will give the client an IP address. Is there other ways to go about > this. I know Road Runner and others do this. DO you have any idea how it > is done ?. From reading over the dhcp RFC's there is nothing > built in that > I can see. ANy help would be appreciated A LOT > > Thanks > > Jim G > From dhcp-v4@bucknell.edu Fri Apr 30 22:28:25 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16838 for ; Fri, 30 Apr 1999 22:28:24 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id WAA29313; Fri, 30 Apr 1999 22:23:13 -0400 (EDT) Date: Fri, 30 Apr 1999 22:23:13 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: waa@dsl.cis.upenn.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "William A. Arbaugh" To: Multiple recipients of list Subject: Re: dhcp + Authentication X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 Base DHCP authentication does not provide authentication, however, a draft has been published (see Ralph Droms site www.dhcp.org). There are a few issues that have been resolved but are not in the current draft. I hope to publish a new draft within a few weeks. Please look at the current one and ask any questions you like. As for RoadRunner, I have no idea what they are doing. I would like to hear if anyone knows. Bill On Fri, 30 Apr 1999, Jim Greene wrote: > Hello Group... > I have a question regarding the use of DHCP and authentication. > Is there a way to make the client provide authentication information before > dhcpd will give the client an IP address. Is there other ways to go about > this. I know Road Runner and others do this. DO you have any idea how it > is done ?. From reading over the dhcp RFC's there is nothing built in that > I can see. ANy help would be appreciated A LOT > > Thanks > > Jim G > >