From: David Hankins Date: Thu, 17 Mar 2005 20:42:06 +0000 (+0000) Subject: Files removed in the massive merge between V3-RELEASE-BRANCH and HEAD, X-Git-Tag: HEAD-MERGE-V3-0-3RC1_base~1 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9748a78039d741f844f0db04d4f2100fa1050496;p=thirdparty%2Fdhcp.git Files removed in the massive merge between V3-RELEASE-BRANCH and HEAD, bringing HEAD up to par with V3-0-3-BETA-1. --- diff --git a/ANONCVS b/ANONCVS deleted file mode 100644 index fa363db18..000000000 --- a/ANONCVS +++ /dev/null @@ -1,129 +0,0 @@ - Anonymous CVS Access for the ISC DHCP Distribution - -The ISC DHCP distribution can be accessed using "anonymous" CVS. -"Anonymous" cvs uses the CVS "pserver" mechanism to allow anybody on -the Internet to access a CVS repository without having to register in -any way. Anonymous CVS allows you to access changes as soon as the -DHCP developers commit them, rather than having to wait for the next -snapshot or patchlevel. Changes that have not yet been released yet -are not guaranteed to work, but they can nonetheless be useful in many -cases. - - TABLE OF CONTENTS - - 1. What is anonymous CVS? - 2. How can i start using it? - 3. Checking out the latest code in a release - 4. Checking out the latest code - 5. Checking out a specific release - 6. When to update - - WHAT IS ANONYMOUS CVS? - -Anonymous CVS also allows you to browse through the history of the -DHCP distribution, and examine the revision history of specific files -to see how they have changed between revisions, to try to figure out -why something that was working before is no longer working, or just to -see when a certain change was made. - - HOW CAN I START USING IT? - -To use anonymous CVS to access the DHCP distribution, you must first -"log in". You should only need to do this once, but it is a -necessary step, even though access is anonymous. Anonymous users log -in as user "nobody", password "nobody". To do this, type: - - cvs -d :pserver:nobody@dhcp.cvs.isc.org:/cvsroot login - -You will be prompted for a password - type "nobody". If you get some -kind of error indicating that cvs doesn't know how to log you in, you -are probably running an old version of cvs, and should upgrade. This -should work with cvs version 1.10. - -Once you have logged in, you can check out a version of the DHCP -distribution, so the next question is, which version? - - CHECKING OUT THE LATEST CODE IN A RELEASE - -There are currently four major versions of the distribution - Release -1, Release 2, Release 3, and the current development tree. Releases -1, 2 and 3 are branches in the CVS repository. To check out the -latest code on any of these branches, you would use a branch tag of -RELEASE_1, RELEASE_2 or RELEASE_3 in the following command: - - (setenv CVSROOT :pserver:nobody@dhcp.cvs.isc.org:/cvsroot; - cvs checkout -d dhcp-2.0 -r RELEASE_2 DHCP) - -Note that the example is for Release 2. - - CHECKING OUT THE LATEST CODE - -To check out the current engineering version, use: - - (setenv CVSROOT :pserver:nobody@dhcp.cvs.isc.org:/cvsroot; - cvs checkout -d dhcp-current DHCP) - -Note that the current engineering version is a work in progress, and -there is no real guarantee that it will work for you. - - CHECKING OUT A SPECIFIC RELEASE - -You can also check out specific versions of the DHCP distribution. -There are three kinds of version tags you may find - alpha tags, beta -tags and release tags. Alpha tags look like this: - - V#-ALPHA-YYYYMMDD - -# is the release number. YYYYMMDD is the date of the release, with a -4-digit year, the month expressed as a number (January=1), and the day -of the month specified as a number, with the first day of the month -being 1. - -Beta tags look like this: - - V#-BETA-%-PATCH-* - -Where # is the release number, % is the Beta number (usually 1) and * -is the patchlevel. In the future there may also be beta tags that -look like this: - - V#-#-BETA-%-PATCH-* - -Where #-# is the major version followed by the minor version - for -example, when the first 3.1 beta comes out, the tag will look like -this: - - V3-1-BETA-1-PATCH-0 - -Release tags look like this: - - V#-%-* - -Where # is the major version, % is the minor version, and * is the -patchlevel. So the tag for 1.0pl2 is V1-0-2, and to check it out, -you'd type: - - (setenv CVSROOT :pserver:nobody@dhcp.cvs.isc.org:/cvsroot; - cvs checkout -d dhcp-1.0pl2 -rV1-0-2 DHCP) - -Whenever changes are checked in to the ISC DHCP repository, or files -are tagged, a notice is sent to the dhcp-source-changes@isc.org -mailing list. You can subscribe to this list by sending mail to -dhcp-source-changes-request@isc.org, and you will then get immediate -notification when changes are made. You may find the volume of mail -on this list annoying, however. - - WHEN TO UPDATE - -We do not recommend that you do an update immediately after you see a -change on the dhcp-source-changes mailing list - instead, it's best to -wait a while to make sure that any changes that change depends on have -also been committed. Also, sometimes when development is being done -on two machines, the developers will check in a tentative change that -hasn't been tested at all so that they can update on a different -machine and test the change. The best way to avoid accidentally -getting one of these changes is to not update aggressively - when a -change is made, wait a while before updating, to make sure that it's -not going to be quickly followed by another change. - - diff --git a/CHANGES b/CHANGES deleted file mode 100644 index 471929701..000000000 --- a/CHANGES +++ /dev/null @@ -1,104 +0,0 @@ -970609 - -- Don't trust hostnames provided by client - Win95 allows *spaces* in - client-supplied hostnames! - -- Be lenient in parsing client-hostname statement in case a bad hostname - got recorded. - -970607 - -- Change size_t to ssize_t in return values where a negative number - is used to indicate an error. - -- Always write out two digits for single-byte quantities in arrays. - -- When parsing a lease database, correctly transfer the client - hostname and hostname to the memory-resident lease structure. - -- If the lease we want to give the client is different than the - one it's asking for, and we recognize the one it's asking for as - ours, NAK it. - -- Only accept a DHCPRELEASE or DHCPNAK if the client supplies an IP - address and the lease corresponding to that address is available to - that client. - -- Make it a warning rather than an error if resolv.conf is missing. - -970605 - -- Add client-hostname token to lexer so that the parser can use it. - Fixes a serious lease database bug. - -- Disable log message on receipt of short ICMP Echo replies. - -970602 - -- Added DHCP Client scripts for FreeBSD, Solaris, and Linux, but - they're not guaranteed to work. - -- Added some Cygwin32 (Windows NT/Windows 95) support, but this is not - sufficiently complete to be useful yet. - -- Updated README - -- Put something useful in TODO - formerly it mostly listed projects - that were way out on the back burner. - -In DHCP Client: - -- Add default, supersede, prepend and append option support, so that a - client can override or modify server-supplied options, and provide - default values if the server provides no values. - -- Add reject keyword, so that packets from rogue DHCP or BOOTP servers - can be rejected out of hand. - -- Added support for booting from BOOTP servers. - -- Added BOOTP flag to client lease declaration, to indicated that a - particular lease was acquired through a BOOTP server. - -- Don't try to do INIT-REBOOT on leases acquired from BOOTP servers. - -- Print server's IP address instead of its IP address when logging - DHCP/BOOTP messages received by client. - -- Fix some bugs in saved lease activation. - -- Fix some scripting bugs. - -- New sample dhclient.conf script demonstrates new features. - -In common code: - -- Partially implemented asynchronous DNS lookups. - -- Fixed some bugs in dispatch routine. - -- Fix date parsing bug that was setting dates forward one day every - time dhcpd was restarted (this has been fixed for a while in the 1.0 - branch). - -- Change name-server option name to ien116-name-server so as to reduce - the potential for confusion. - -DHCP Relay daemon: - -- Fixed an operator precedence bug having to do with the broadcast - flag. - -DHCP Server: - -- Add support to record the client-supplied hostname in the lease file, - for better readability. - -- Fixed a bug in the renewal code that resulted in the server ignoring - unicast renewals from non-local subnets. This bug caused some - heartburn for Win95 machines. - -- Copy ciaddr from saved ciaddr, not from giaddr. - -- New -t flag tests /etc/dhcpd.conf for syntax errors. - diff --git a/COPYRIGHT b/COPYRIGHT deleted file mode 100644 index 0e5d81aa6..000000000 --- a/COPYRIGHT +++ /dev/null @@ -1,17 +0,0 @@ -/* - * Copyright (c) 1996-1999 Internet Software Consortium. - * Use is subject to license terms which appear in the file named - * ISC-LICENSE that should have accompanied this file when you - * received it. If a file named ISC-LICENSE did not accompany this - * file, or you are not sure the one you have is correct, you may - * obtain an applicable copy of the license at: - * - * http://www.isc.org/isc-license-1.0.html. - * - * This file is part of the ISC DHCP distribution. The documentation - * associated with this file is listed in the file DOCUMENTATION, - * included in the top-level directory of this release. - * - * Support and other services are available for ISC products - see - * http://www.isc.org for more information. - */ diff --git a/common/auth.c b/common/auth.c deleted file mode 100644 index 150f9ebbb..000000000 --- a/common/auth.c +++ /dev/null @@ -1,72 +0,0 @@ -/* auth.c - - Subroutines having to do with authentication. */ - -/* - * Copyright (c) 1998-2000 Internet Software Consortium. - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in the - * documentation and/or other materials provided with the distribution. - * 3. Neither the name of The Internet Software Consortium nor the names - * of its contributors may be used to endorse or promote products derived - * from this software without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE INTERNET SOFTWARE CONSORTIUM AND - * CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, - * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE - * DISCLAIMED. IN NO EVENT SHALL THE INTERNET SOFTWARE CONSORTIUM OR - * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF - * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, - * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT - * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF - * SUCH DAMAGE. - * - * This software has been written for the Internet Software Consortium - * by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc. - * To learn more about the Internet Software Consortium, see - * ``http://www.isc.org/''. To learn more about Vixie Enterprises, - * see ``http://www.vix.com''. To learn more about Nominum, Inc., see - * ``http://www.nominum.com''. - */ - -#ifndef lint -static char ocopyright[] = -"$Id: auth.c,v 1.6 2000/03/18 02:15:36 mellon Exp $ Copyright 1998-2000 The Internet Software Consortium."; -#endif - -#include "dhcpd.h" - -static struct hash_table *auth_key_hash; - -void enter_auth_key (key_id, key) - struct data_string *key_id; - struct auth_key *key; -{ - if (!auth_key_hash) - auth_key_hash = new_hash (0, 0, 0); - if (!auth_key_hash) - log_fatal ("Can't allocate authentication key hash."); - add_hash (auth_key_hash, key_id -> data, key_id -> len, - (unsigned char *)key); -} - -const struct auth_key *auth_key_lookup (key_id) - struct data_string *key_id; -{ - return (const struct auth_key *)hash_lookup (auth_key_hash, - key_id -> data, - key_id -> len); -} - diff --git a/common/dhcp-contrib.5 b/common/dhcp-contrib.5 deleted file mode 100644 index c3f15c08f..000000000 --- a/common/dhcp-contrib.5 +++ /dev/null @@ -1,214 +0,0 @@ -.\" dhcp-contrib.5 -.\" -.\" Copyright (c) 1996-1999 Internet Software Consortium. -.\" Use is subject to license terms which appear in the file named -.\" ISC-LICENSE that should have accompanied this file when you -.\" received it. If a file named ISC-LICENSE did not accompany this -.\" file, or you are not sure the one you have is correct, you may -.\" obtain an applicable copy of the license at: -.\" -.\" http://www.isc.org/isc-license-1.0.html. -.\" -.\" This file is part of the ISC DHCP distribution. The documentation -.\" associated with this file is listed in the file DOCUMENTATION, -.\" included in the top-level directory of this release. -.\" -.\" Support and other services are available for ISC products - see -.\" http://www.isc.org for more information. -.TH dhcp-contrib 5 -.SH NAME -Contributing to the Internet Software Consortium DHCP Distribution -.SH EXHORTATION -.PP -The Internet Software Consortium DHCP Distribution has historically -been funded through the donation of various charitable and -non-charitable organizations, as well as by individual contributions. -To some degree, support for the distribution has been done on a -volunteer basis, but by and large the reason that you have this -distribution in your hands right now is because people like you have -provided funding for it. -.PP -We would like to encourage you to continue to provide such support, or -to begin providing it if you have not in the past. You are in no way -obliged to provide us with any support at all, and this message is not -intended to guilt-trip you about providing support. If you choose -not to provide support, for whatever reason, you aren't going to be -treated differently on the mailing lists, and your requests for -features aren't going to be prioritized any differently. If you want -to be treated differently, you can buy a formal support contract, of -course, but this document is about contributions, not support -contracts. -.SH FREQUENTLY ASKED QUESTIONS -.PP -Q: So if I won't be treated differently, why contribute? -.PP -A: The obvious -answer is self-interest. If you contribute, it means that the author -will have time to work on stuff that's not of the utmost high -priority. People are constantly asking for things that we would -really like to provide, but for which we have no time. By -contributing, you are literally giving us time to do these things. -The amount of time varies with the contribution, of course, but if -everybody contributes a little bit, it can add up to a lot. -.PP -Q: But everybody isn't required to contribute. If I contribute and -nobody else does, doesn't that make me kind of a sucker? -.PP -A: Obviously, we don't think so, but think about this: if you contribute, -then we can point out to others that we've received contributions, and -this will make the idea of contributing seem more legitimate to them, -making it more likely that they will contribute. So your -contribution has more value than just the money you provide - it also -helps us to raise funds from others. -.PP -Q: If I contribute, I want a say in what work gets done. -.PP -A: We do sell support contracts, and we will also do development work -on specification if we feel it is relevant (although you won't get to -own it). This can be quite expensive, though - much more than even -the maximum we'd expect you to donate. So no, contributing doesn't -buy you a say in what work gets done. -.PP -Q: I work for a charity that feeds the homeless. Should my charity -contribute? -.PP -A: Absolutely not! The idea here is not to take food out of the mouths -of poor people. If donating to us would mean that somebody in need -that you could have helped will go without help, keep the money. -It's not worth it to us. This goes for providing shelter, -psychiatric aid, legal assistance, and any other similar charity work. -.PP -Q: Cool! I work for a university, helping students who are in need of -an education, so we shouldn't contribute, right? -.PP -A: No, that's not quite what we mean. Sure, if you work for an -organization that provides free education to needy people, at whatever -level, then we'd rather you did that than support us. But if your -university has a big budget for running the computer center, can -afford to plant nice gardens and maintain nice lawns, and maybe has -all its dorms wired for ethernet, then even if you qualify as a -nonprofit under federal law (or the law in your own country) you -should still contribute. DHCP is just as much a part of your -infrastructure as your campus wiring. -.PP -Q: This software came on a CD that I bought. Haven't I already -contributed? -.PP -A: If you're seeing this notice, and you didn't see a notice saying -that the people who sold you your CD contributed to us, then no, you -haven't already contributed. In general, we encourage people to -include this software on their distributions if they feel it would be -useful, and we do not require them to contribute in exchange for that -privilege. -.PP -Q: I've contributed to the development of this software by submitting bug -reports and patches. Why should I also contribute money? -.PP -A: When you contributed these bug reports and patches, was there zero -effort involved on our part in integrating the patches or figuring out -what was wrong? Probably not. Bug reports and patches can be -extremely valuable, and we can't say that in no event do they qualify -you to get out of contributing - after all, we're leaving that up to -your judgement anyway, aren't we? But unless your contribution was -pretty massive, and is actually in this distribution, we aren't likely -to agree with you about this. -.PP -Q: Software should be free. You have no right to ask for money to -support this effort. -.PP -A: You are entitled to that opinion, but please don't raise it on the -mailing list, as it will tend to get people excited. Please remember -that while copying software is generally a very cheap process, -creating it is not. The amount of work that's gone into this software -package is quite significant, and there's plenty more work to do. If -you happen to be in college, working toward your degree, and have no -social life (and yes, I've been there and done that) then it can seem -like there's no additional cost to hacking on software - after all, -it's fun, isn't it? While this is true, it is also true that you're a -lot better off with this software than you would have been with the -software I wrote in college. Enough said? -.PP -Q: Can't I contribute work instead of software? -.PP -A: We'd like to encourage that to some extent, and are indeed trying to -bring some developers into the fold, but you shouldn't expect that -your willingness to do this translates directly into an opportunity. -For example, you may want very much to work for [insert the name of -your favorite commercial Linux vendor here], but unless you have the -appropriate skills, they like you, they're willing to pay what you -need, and they have work that's appropriate to your skills, you're not -going to get hired there. -.PP -Q: I don't contribute to the Free Software Foundation - why do you rate? -.PP -A: You should contribute to the Free Software Foundation too! -.PP -Q: I don't contribute to [insert name of your local food bank here]. -Why do you rate? -.PP -A: If you feel bad about not contributing to the local food bank, this is -a very easy problem to solve, and we encourage you to do so. -.PP -Q: Once I've contributed once, am I done? -.PP -A: We'd like to encourage you to contribute once a year. If you want, -we can send you a reminder notice on the year anniversary of your -original contribution. If you don't specifically ask for this, we -won't force it on you. No salesperson will call. No spam will be -sent. We definitely won't try to convince you that it's been a year -since you last contributed when it hasn't been a year yet. -.PP -Q: I don't have you in my budget this year. -.PP -A: Fine, put us in your budget for next year! -.PP -Q: It's really hard to do charitable contributions at my organization. -.PP -A: We'd be happy to sell you a product instead. If you choose to go -down this route, what we'l sell you is a license for some number of -clients and a CD. Just let us know how many DHCP clients you have, -and we'll use the following schedule to figure out how much to invoice -you (shipping is included on orders of $100 or more). Even if you can -do charitable contributions, you might want to use this schedule as a -guideline for figuring out how much to donate. It is only a -guideline, of course - if the amounts listed feel like too much or too -little to you, do what seems appropriate. -.PP -.nf - $10k for businesses supporting >10k nodes - $5k for charities supporting >10k nodes - $2.5k for businesses supporting >1k nodes - $1k for charities supporting >1k nodes - $500 for businesses with >500 nodes - $250 for charities with >500 nodes - $200 for businesses with >150 nodes - $100 for charities with >150 nodes - $100 for businesses with <150 nodes - $50 for charities with <150 nodes - $25 for home use, client or server - $0.10 to $1 per client for businesses that are reselling the - client, depending on volume. -.fi -.PP -Q: Are you nuts? I live in [insert your country name here] and the -typical annual salary for a programmer is less than what you're asking -me to contribute! -.PP -A: We leave the choice of how much to contribute up to you. Really. -We aren't kidding. -.PP -Q: Can I contribute with my credit card? -.PP -A: Yes. The details haven't been ironed out at this writing, but if you -send mail to dhcp-contributions@isc.org, we'll work it out. By the -time you read this, we may have a web interface set up - if so, it -will be linked in at http://www.isc.org/dhcp-contrib.html. -.SH SEE ALSO -dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcpd(8), -dhclient(8), RFC2132, RFC2131. -.SH AUTHOR -The Internet Software Consortium DHCP Distribution was written by Ted -Lemon under a contract with Vixie Labs. Funding for -this project was provided through the Internet Software Consortium. -Information about the Internet Software Consortium can be found at -.B http://www.isc.org/isc. diff --git a/common/dhcp-contrib.cat5 b/common/dhcp-contrib.cat5 deleted file mode 100644 index 9b81be989..000000000 --- a/common/dhcp-contrib.cat5 +++ /dev/null @@ -1,330 +0,0 @@ - - - -dhcp-contrib(5) dhcp-contrib(5) - - -NNAAMMEE - Contributing to the Internet Software Consortium DHCP Dis­ - tribution - -EEXXHHOORRTTAATTIIOONN - The Internet Software Consortium DHCP Distribution has - historically been funded through the donation of various - charitable and non-charitable organizations, as well as by - individual contributions. To some degree, support for the - distribution has been done on a volunteer basis, but by - and large the reason that you have this distribution in - your hands right now is because people like you have pro­ - vided funding for it. - - We would like to encourage you to continue to provide such - support, or to begin providing it if you have not in the - past. You are in no way obliged to provide us with any - support at all, and this message is not intended to guilt- - trip you about providing support. If you choose not to - provide support, for whatever reason, you aren't going to - be treated differently on the mailing lists, and your - requests for features aren't going to be prioritized any - differently. If you want to be treated differently, you - can buy a formal support contract, of course, but this - document is about contributions, not support contracts. - -FFRREEQQUUEENNTTLLYY AASSKKEEDD QQUUEESSTTIIOONNSS - Q: So if I won't be treated differently, why contribute? - - A: The obvious answer is self-interest. If you con­ - tribute, it means that the author will have time to work - on stuff that's not of the utmost high priority. People - are constantly asking for things that we would really like - to provide, but for which we have no time. By contribut­ - ing, you are literally giving us time to do these things. - The amount of time varies with the contribution, of - course, but if everybody contributes a little bit, it can - add up to a lot. - - Q: But everybody isn't required to contribute. If I con­ - tribute and nobody else does, doesn't that make me kind of - a sucker? - - A: Obviously, we don't think so, but think about this: if - you contribute, then we can point out to others that we've - received contributions, and this will make the idea of - contributing seem more legitimate to them, making it more - likely that they will contribute. So your contribution - has more value than just the money you provide - it also - helps us to raise funds from others. - - Q: If I contribute, I want a say in what work gets done. - - A: We do sell support contracts, and we will also do - - - - 1 - - - - - -dhcp-contrib(5) dhcp-contrib(5) - - - development work on specification if we feel it is rele­ - vant (although you won't get to own it). This can be - quite expensive, though - much more than even the maximum - we'd expect you to donate. So no, contributing doesn't - buy you a say in what work gets done. - - Q: I work for a charity that feeds the homeless. Should - my charity contribute? - - A: Absolutely not! The idea here is not to take food out - of the mouths of poor people. If donating to us would - mean that somebody in need that you could have helped will - go without help, keep the money. It's not worth it to us. - This goes for providing shelter, psychiatric aid, legal - assistance, and any other similar charity work. - - Q: Cool! I work for a university, helping students who - are in need of an education, so we shouldn't contribute, - right? - - A: No, that's not quite what we mean. Sure, if you work - for an organization that provides free education to needy - people, at whatever level, then we'd rather you did that - than support us. But if your university has a big budget - for running the computer center, can afford to plant nice - gardens and maintain nice lawns, and maybe has all its - dorms wired for ethernet, then even if you qualify as a - nonprofit under federal law (or the law in your own coun­ - try) you should still contribute. DHCP is just as much a - part of your infrastructure as your campus wiring. - - Q: This software came on a CD that I bought. Haven't I - already contributed? - - A: If you're seeing this notice, and you didn't see a - notice saying that the people who sold you your CD con­ - tributed to us, then no, you haven't already contributed. - In general, we encourage people to include this software - on their distributions if they feel it would be useful, - and we do not require them to contribute in exchange for - that privilege. - - Q: I've contributed to the development of this software by - submitting bug reports and patches. Why should I also - contribute money? - - A: When you contributed these bug reports and patches, was - there zero effort involved on our part in integrating the - patches or figuring out what was wrong? Probably not. - Bug reports and patches can be extremely valuable, and we - can't say that in no event do they qualify you to get out - of contributing - after all, we're leaving that up to your - judgement anyway, aren't we? But unless your contribution - was pretty massive, and is actually in this distribution, - - - - 2 - - - - - -dhcp-contrib(5) dhcp-contrib(5) - - - we aren't likely to agree with you about this. - - Q: Software should be free. You have no right to ask for - money to support this effort. - - A: You are entitled to that opinion, but please don't - raise it on the mailing list, as it will tend to get peo­ - ple excited. Please remember that while copying software - is generally a very cheap process, creating it is not. - The amount of work that's gone into this software package - is quite significant, and there's plenty more work to do. - If you happen to be in college, working toward your - degree, and have no social life (and yes, I've been there - and done that) then it can seem like there's no additional - cost to hacking on software - after all, it's fun, isn't - it? While this is true, it is also true that you're a lot - better off with this software than you would have been - with the software I wrote in college. Enough said? - - Q: Can't I contribute work instead of software? - - A: We'd like to encourage that to some extent, and are - indeed trying to bring some developers into the fold, but - you shouldn't expect that your willingness to do this - translates directly into an opportunity. For example, you - may want very much to work for [insert the name of your - favorite commercial Linux vendor here], but unless you - have the appropriate skills, they like you, they're will­ - ing to pay what you need, and they have work that's appro­ - priate to your skills, you're not going to get hired - there. - - Q: I don't contribute to the Free Software Foundation - - why do you rate? - - A: You should contribute to the Free Software Foundation - too! - - Q: I don't contribute to [insert name of your local food - bank here]. Why do you rate? - - A: If you feel bad about not contributing to the local - food bank, this is a very easy problem to solve, and we - encourage you to do so. - - Q: Once I've contributed once, am I done? - - A: We'd like to encourage you to contribute once a year. - If you want, we can send you a reminder notice on the year - anniversary of your original contribution. If you don't - specifically ask for this, we won't force it on you. No - salesperson will call. No spam will be sent. We defi­ - nitely won't try to convince you that it's been a year - since you last contributed when it hasn't been a year yet. - - - - 3 - - - - - -dhcp-contrib(5) dhcp-contrib(5) - - - Q: I don't have you in my budget this year. - - A: Fine, put us in your budget for next year! - - Q: It's really hard to do charitable contributions at my - organization. - - A: We'd be happy to sell you a product instead. If you - choose to go down this route, what we'l sell you is a - license for some number of clients and a CD. Just let us - know how many DHCP clients you have, and we'll use the - following schedule to figure out how much to invoice you - (shipping is included on orders of $100 or more). Even if - you can do charitable contributions, you might want to use - this schedule as a guideline for figuring out how much to - donate. It is only a guideline, of course - if the - amounts listed feel like too much or too little to you, do - what seems appropriate. - - $10k for businesses supporting >10k nodes - $5k for charities supporting >10k nodes - $2.5k for businesses supporting >1k nodes - $1k for charities supporting >1k nodes - $500 for businesses with >500 nodes - $250 for charities with >500 nodes - $200 for businesses with >150 nodes - $100 for charities with >150 nodes - $100 for businesses with <150 nodes - $50 for charities with <150 nodes - $25 for home use, client or server - $0.10 to $1 per client for businesses that are reselling the - client, depending on volume. - - Q: Are you nuts? I live in [insert your country name - here] and the typical annual salary for a programmer is - less than what you're asking me to contribute! - - A: We leave the choice of how much to contribute up to - you. Really. We aren't kidding. - - Q: Can I contribute with my credit card? - - A: Yes. The details haven't been ironed out at this - writing, but if you send mail to dhcp-contribu­ - tions@isc.org, we'll work it out. By the time you read - this, we may have a web interface set up - if so, it will - be linked in at http://www.isc.org/dhcp-contrib.html. - -SSEEEE AALLSSOO - dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), - dhcpd(8), dhclient(8), RFC2132, RFC2131. - -AAUUTTHHOORR - The Internet Software Consortium DHCP Distribution was - - - - 4 - - - - - -dhcp-contrib(5) dhcp-contrib(5) - - - written by Ted Lemon under a contract - with Vixie Labs. Funding for this project was provided - through the Internet Software Consortium. Information - about the Internet Software Consortium can be found at - hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5 - - diff --git a/common/dhcp-eval.cat5 b/common/dhcp-eval.cat5 deleted file mode 100644 index ada5beb48..000000000 --- a/common/dhcp-eval.cat5 +++ /dev/null @@ -1,462 +0,0 @@ - - - -dhcpd-options(5) dhcpd-options(5) - - -NNAAMMEE - dhcp-conditionals - ISC DHCP conditional evaluation - -DDEESSCCRRIIPPTTIIOONN - The Internet Software Consortium DHCP client and server - both provide the ability to perform conditional behavior - depending on the contents of packets they receive. The - syntax for specifying this conditional behaviour is docu­ - mented here. - -RREEFFEERREENNCCEE:: CCOONNDDIITTIIOONNAALL BBEEHHAAVVIIOOUURR - Conditional behaviour is specified using the if statement - and the else or elsif statements. A conditional state­ - ment can appear anywhere that a regular statement (e.g., - an option statement) can appear, and can enclose one or - more such statements. A typical conditional statement in - a server might be: - - if option dhcp-user-class = "accounting" { - max-lease-time 17600; - option domain-name "accounting.example.org"; - option domain-name-servers ns1.accounting.example.org, - ns2.accounting.example.org; - } elsif option dhcp-user-class = "sales" { - max-lease-time 17600; - option domain-name "sales.example.org"; - option domain-name-servers ns1.sales.example.org, - ns2.sales.example.org; - } elsif option dhcp-user-class = "engineering" { - max-lease-time 17600; - option domain-name "engineering.example.org"; - option domain-name-servers ns1.engineering.example.org, - ns2.engineering.example.org; - } else { - max-lease-time 600; - option domain-name "misc.example.org"; - option domain-name-servers ns1.misc.example.org, - ns2.misc.example.org; - } - - On the client side, an example of conditional evaluation - might be: - - # example.org filters DNS at its firewall, so we have to use their DNS - # servers when we connect to their network. If we are not at - # example.org, prefer our own DNS server. - if not option domain-name = "example.org" { - prepend domain-name-servers 127.0.0.1; - } - - The iiff statement and the eellssiiff continuation statement both - take boolean expressions as their arguments. That is, - they take expressions that, when evaluated, produce a - boolean result. If the expression evaluates to true, - - - - 1 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - then the statements enclosed in braces following the iiff - statement are executed, and all subsequent eellssiiff and eellssee - clauses are skipped. Otherwise, each subsequent eellssiiff - clause's expression is checked, until an elsif clause is - encountered whose test evaluates to true. If such a - clause is found, the statements in braces following it are - executed, and then any subsequent eellssiiff and eellssee clauses - are skipped. If all the iiff and eellssiiff clauses are checked - but none of their expressions evaluate true, then if there - is an eellssee clause, the statements enclosed in braces fol­ - lowing the eellssee are evaluated. Boolean expressions that - evaluate to null are treated as false in conditionals. - -BBOOOOLLEEAANN EEXXPPRREESSSSIIOONNSS - The following is the current list of boolean expressions - that are supported by the DHCP distribution. - - cchheecckk _c_l_a_s_s_-_n_a_m_e - - The check operator returns a true value if the packet - being considered comes from a client that falls into - the specified class. _C_l_a_s_s_-_n_a_m_e must be a string that - corresponds to the name of a defined class. Classes - are only supported in the DHCP server. - - _d_a_t_a_-_e_x_p_r_e_s_s_i_o_n_-_1 == _d_a_t_a_-_e_x_p_r_e_s_s_i_o_n_-_2 - - The == operator compares the values of two data expres­ - sions, returning true if they are the same, false if - they are not. If either the left-hand side or the - right-hand side are null, the result is also null. - - _b_o_o_l_e_a_n_-_e_x_p_r_e_s_s_i_o_n_-_1 aanndd _b_o_o_l_e_a_n_-_e_x_p_r_e_s_s_i_o_n_-_2 - - The aanndd operator evaluates to true if the boolean - expression on the left-hand side and the boolean - expression on the right-hand side both evaluate to - true. Otherwise, it evaluates to false. If either the - expression on the left-hand side or the expression on - the right-hand side are null, the result is null. - - _b_o_o_l_e_a_n_-_e_x_p_r_e_s_s_i_o_n_-_1 oorr _b_o_o_l_e_a_n_-_e_x_p_r_e_s_s_i_o_n_-_2 - - The oorr operator evaluates to true if either the boolean - expression on the left-hand side or the boolean expres­ - sion on the right-hand side evaluate to true. Other­ - wise, it evaluates to false. If either the expression - on the left-hand side or the expression on the right- - hand side are null, the result is null. - - nnoott _b_o_o_l_e_a_n_-_e_x_p_r_e_s_s_i_o_n - - The nnoott operator evaluates to true if _b_o_o_l_e_a_n_-_e_x_p_r_e_s_­ - _s_i_o_n evaluates to false, and returns false if _b_o_o_l_e_a_n_- - - - - 2 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - _e_x_p_r_e_s_s_i_o_n evaluates to true. If _b_o_o_l_e_a_n_-_e_x_p_r_e_s_s_i_o_n - evaluates to null, the result is also null. - - eexxiissttss _o_p_t_i_o_n_-_n_a_m_e - - The eexxiissttss expression returns true if the specified - option exists in the incoming DHCP packet being pro­ - cessed. - kknnoowwnn - - The kknnoowwnn expression returns true if the client whose - request is currently being processed is known - that - is, if there's a host declaration for it. - ssttaattiicc - - The ssttaattiicc expression returns true if the lease - assigned to the client whose request is currently being - processed is derived from a static address assignment. - -DDAATTAA EEXXPPRREESSSSIIOONNSS - Several of the boolean expressions above depend on the - results of evaluating data expressions. A list of these - expressions is provided here. - - ssuubbssttrriinngg ((_d_a_t_a_-_e_x_p_r,, _o_f_f_s_e_t,, _l_e_n_g_t_h)) - - The ssuubbssttrriinngg operator evaluates the data expression - and returns the substring of the result of that evalua­ - tion that starts _o_f_f_s_e_t bytes from the beginning, con­ - tinuing for _l_e_n_g_t_h bytes. _O_f_f_s_e_t and _l_e_n_g_t_h are both - numeric expressions. If _d_a_t_a_-_e_x_p_r, _o_f_f_s_e_t or _l_e_n_g_t_h - evaluate to null, then the result is also null. If - _o_f_f_s_e_t is greater than or equal to the length of the - evaluated data, then a zero-length data string is - returned. If _l_e_n_g_t_h _i_s _g_r_e_a_t_e_r _t_h_e_n _t_h_e _r_e_m_a_i_n_i_n_g - _l_e_n_g_t_h _o_f _t_h_e _e_v_a_l_u_a_t_e_d _d_a_t_a _a_f_t_e_r _o_f_f_s_e_t, then a data - string containing all data from _o_f_f_s_e_t to the end of - the evaluated data is returned. - - ssuuffffiixx ((_d_a_t_a_-_e_x_p_r,, _l_e_n_g_t_h)) - - The ssuuffffiixx operator evaluates _d_a_t_a_-_e_x_p_r and returns the - last _l_e_n_g_t_h bytes of the result of that evaluation. - _L_e_n_g_t_h is a numeric expression. If _d_a_t_a_-_e_x_p_r or _l_e_n_g_t_h - evaluate to null, then the result is also null. If - _s_u_f_f_i_x evaluates to a number greater than the length of - the evaluated data, then the evaluated data is - returned. - - ooppttiioonn _o_p_t_i_o_n_-_n_a_m_e - - The ooppttiioonn operator returns the contents of the speci­ - fied option in the packet to which the server is - responding. - - - - 3 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - hhaarrddwwaarree - - The hhaarrddwwaarree operator returns a data string whose first - element is the type of network interface indicated in - packet being considered, and whose subsequent elements - are client's link-layer address. If there is no - packet, or if the RFC2131 _h_l_e_n field is invalid, then - the result is null. Hardware types include ethernet - (1), token-ring (6), and fddi (8). Hardware types are - specified by the IETF, and details on how the type num­ - bers are defined can be found in RFC2131 (in the ISC - DHCP distribution, this is included in the doc/ subdi­ - rectory). - - ppaacckkeett ((_o_f_f_s_e_t,, _l_e_n_g_t_h)) - - The ppaacckkeett operator returns the specified portion of - the packet being considered, or null in contexts where - no packet is being considered. _O_f_f_s_e_t and _l_e_n_g_t_h are - applied to the contents packet as in the ssuubbssttrriinngg - operator. - - _s_t_r_i_n_g - - A string, enclosed in quotes, may be specified as a - data expression, and returns the text between the - quotes, encoded in ASCII. - - _c_o_l_o_n_-_s_e_p_e_r_a_t_e_d _h_e_x_a_d_e_c_i_m_a_l _l_i_s_t - - A list of hexadecimal octet values, seperated by - colons, may be specified as a data expression. - - ccoonnccaatt ((_d_a_t_a_-_e_x_p_r_1,, ......,, _d_a_t_a_-_e_x_p_r_N)) - The expressions are evaluated, and the results of each - evaluation are concatenated in the sequence that the - subexpressions are listed. If any subexpression eval­ - uates to null, the result of the concatenation is null. - - rreevveerrssee ((_n_u_m_e_r_i_c_-_e_x_p_r_1,, _d_a_t_a_-_e_x_p_r_2)) - The two expressions are evaluated, and then the result - of evaluating the data expression is reversed in place, - using hunks of the size specified in the numeric - expression. For example, if the numeric expression - evaluates to four, and the data expression evaluates to - twelve bytes of data, then the reverse expression will - evaluate to twelve bytes of data, consisting of the - last four bytes of the the input data, followed by the - middle four bytes, followed by the first four bytes. - - lleeaasseedd--aaddddrreessss - In any context where the client whose request is being - processed has been assigned an IP address, this data - expression returns that IP address. - - - - 4 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - bbiinnaarryy--ttoo--aasscciiii ((_n_u_m_e_r_i_c_-_e_x_p_r_1,, _n_u_m_e_r_i_c_-_e_x_p_r_2,, _d_a_t_a_-_e_x_p_r_1,, - _d_a_t_a_-_e_x_p_r_2)) - Converts the result of evaluating data-expr2 into a - text string containing one number for each element of - the result of evaluating data-expr2. Each number is - seperated from the other by the result of evaluating - data-expr1. The result of evaluating numeric-expr1 - specifies the base (2 through 16) into which the num­ - bers should be converted. The result of evaluating - numeric-expr2 specifies the width in bits of each num­ - ber, which may be either 8, 16 or 32. - - As an example of the preceding three types of expres­ - sions, to produce the name of a PTR record for the IP - address being assigned to a client, one could write the - following expression: - - concat (binary-to-ascii (10, 8, ".", - reverse (1, leased-address)), - ".in-addr.arpa."); - - - eennccooddee--iinntt ((_n_u_m_e_r_i_c_-_e_x_p_r,, _w_i_d_t_h)) - Numeric-expr is evaluated and encoded as a data string - of the specified width, in network byte order (most - significant byte first). If the numeric expression - evaluates to the null value, the result is also null. - - ppiicckk--ffiirrsstt--vvaalluuee ((_d_a_t_a_-_e_x_p_r_1 [ ... _e_x_p_rn ] )) - The pick-first-value function takes any number of - data expressions as its arguments. Each expression - is evaluated, starting with the first in the list, - until an expression is found that does not evaluate - to a null value. That expression is returned, and - none of the subsequent expressions are evaluated. - If all expressions evaluate to a null value, the null - value is returned. - - hhoosstt--ddeeccll--nnaammee - The host-decl-name function returns the name of the - host declaration that matched the client whose - request is currently being processed, if any. If no - host declaration matched, the result is the null - value. - -NNUUMMEERRIICC EEXXPPRREESSSSIIOONNSS - Numeric expressions are expressions that evaluate to an - integer. In general, the maximum size of such an integer - should not be assumed to be representable in fewer than 32 - bits, but the precision of such integers may be more than - 32 bits. - - eexxttrraacctt--iinntt ((_d_a_t_a_-_e_x_p_r,, _w_i_d_t_h)) - - - - - 5 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - The eexxttrraacctt--iinntt operator extracts an integer value in - network byte order from the result of evaluating the - specified data expression. Width is the width in bits - of the integer to extract. Currently, the only sup­ - ported widths are 8, 16 and 32. If the evaluation of - the data expression doesn't provide sufficient bits to - extract an integer of the specified size, the null - value is returned. - - lleeaassee--ttiimmee - - The duration of the current lease - that is, the dif­ - ference between the current time and the time that the - lease expires. - - _n_u_m_b_e_r - - Any number between zero and the maximum representable - size may be specified as a numeric expression. - -RREEFFEERREENNCCEE:: DDYYNNAAMMIICC DDNNSS UUPPDDAATTEESS - The DHCP client and server have the ability to dynamically - update the Domain Name System. Within the configuration - files, you can define how you want the Domain Name System - to be updated. These updates are RFC 2136 compliant so - any DNS server supporting RFC 2136 should be able to - accept updates from the DHCP server. - -SSEECCUURRIITTYY - Support for TSIG and DNSSEC is not yet available. When - you set your DNS server up to allow updates from the DHCP - server or client, you may be exposing it to unauthorized - updates. To avoid this, the best you can do right now is - to use IP address-based packet filtering to prevent unau­ - thorized hosts from submitting update requests. Obvi­ - ously, there is currently no way to provide security for - client updates - this will require TSIG or DNSSEC, neither - of which is yet available in the DHCP distribution. - - Dynamic DNS (DDNS) updates are performed by using the ddnnss-- - uuppddaattee expression. The ddnnss--uuppddaattee expression is a boolean - expression that takes four parameters. If the update suc­ - ceeds, the result is true. If it fails, the result is - false. The four parameters that the are the resource - record type (RR), the left hand side of the RR, the right - hand side of the RR and the ttl that should be applied to - the record. The simplest example of the use of the func­ - tion can be found in the reference section of the - dhcpd.conf file, where events are described. In this - example several statements are being used to make the - arguments to the ddnnss--uuppddaatteeRR.. - - In the example, the first argument to the first Bdns- - update expression is a data expression that evaluates to - - - - 6 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - the A RR type. The second argument is constructed by con­ - catenating the DHCP host-name option with a text string - containing the local domain, in this case "ssd.exam­ - ple.net". The third argument is constructed by converting - the address the client has been assigned from a 32-bit - number into an ascii string with each byte separated by a - ".". The fourth argument, the TTL, specifies the amount - of time remaining in the lease (note that this isn't - really correct, since the DNS server will pass this TTL - out whenever a request comes in, even if that is only a - few seconds before the lease expires). - - If the first ddnnss--uuppddaattee statement succeeds, it is followed - up with a second update to install a PTR RR. The instal­ - lation of a PTR record is similar to installing an A RR - except that the left hand side of the record is the leased - address, reversed, with ".in-addr.arpa" concatenated. The - right hand side is the fully qualified domain name of the - client to which the address is being leased. - -SSEEEE AALLSSOO - dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp- - eval(5), dhcpd(8), dhclient(8), RFC2132, RFC2131. - -AAUUTTHHOORR - The Internet Software Consortium DHCP Distribution was - written by Ted Lemon under a contract - with Vixie Labs. Funding for this project was provided - through the Internet Software Consortium. Information - about the Internet Software Consortium can be found at - hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - - - - - - - - - - - - - 7 - - diff --git a/common/dhcp-options.cat5 b/common/dhcp-options.cat5 deleted file mode 100644 index c87cb22e9..000000000 --- a/common/dhcp-options.cat5 +++ /dev/null @@ -1,1188 +0,0 @@ - - - -dhcpd-options(5) dhcpd-options(5) - - -NNAAMMEE - dhcp-options - Dynamic Host Configuration Protocol options - -DDEESSCCRRIIPPTTIIOONN - The Dynamic Host Configuration protocol allows the client - to receive ooppttiioonnss from the DHCP server describing the - network configuration and various services that are avail­ - able on the network. When configuring ddhhccppdd((88)) or - ddhhcclliieenntt((88)) ,, options must often be declared. The syntax - for declaring options, and the names and formats of the - options that can be declared, are documented here. - -RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS - DHCP _o_p_t_i_o_n statements always start with the _o_p_t_i_o_n key­ - word, followed by an option name, followed by option data. - The option names and data formats are described below. - It is not necessary to exhaustively specify all DHCP - options - only those options which are needed by clients - must be specified. - - Option data comes in a variety of formats, as defined - below: - - The iipp--aaddddrreessss data type can be entered either as an - explicit IP address (e.g., 239.254.197.10) or as a domain - name (e.g., haagen.isc.org). When entering a domain name, - be sure that that domain name resolves to a single IP - address. - - The iinntt3322 data type specifies a signed 32-bit integer. - The uuiinntt3322 data type specifies an unsigned 32-bit integer. - The iinntt1166 and uuiinntt1166 data types specify signed and - unsigned 16-bit integers. The iinntt88 and uuiinntt88 data types - specify signed and unsigned 8-bit integers. Unsigned - 8-bit integers are also sometimes referred to as octets. - - The tteexxtt data type specifies an NVT ASCII string, which - must be enclosed in double quotes - for example, to spec­ - ify a domain-name option, the syntax would be - - option domain-name "isc.org"; - - The ffllaagg data type specifies a boolean value. Booleans - can be either true or false (or on or off, if that makes - more sense to you). - - The ssttrriinngg data type specifies either an NVT ASCII string - enclosed in double quotes, or a series of octets specified - in hexadecimal, seperated by colons. For example: - - option dhcp-client-identifier "CLIENT-FOO"; - or - option dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f; - - - - - 1 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - The documentation for the various options mentioned below - is taken from the latest IETF draft document on DHCP - options. Options which are not listed by name may be - defined by the name option-_n_n_n, where _n_n_n is the decimal - number of the option code. These options may be followed - either by a string, enclosed in quotes, or by a series of - octets, expressed as two-digit hexadecimal numbers seper­ - ated by colons. For example: - - option option-133 "my-option-133-text"; - option option-129 1:54:c9:2b:47; - - Because dhcpd does not know the format of these undefined - option codes, no checking is done to ensure the correct­ - ness of the entered data. - - The standard options are: - - ooppttiioonn aallll--ssuubbnneettss--llooccaall _f_l_a_g;; - - This option specifies whether or not the client may - assume that all subnets of the IP network to which the - client is connected use the same MTU as the subnet of - that network to which the client is directly connected. - A value of true indicates that all subnets share the - same MTU. A value of false means that the client - should assume that some subnets of the directly con­ - nected network may have smaller MTUs. - - ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2;; - - This option specifies the timeout in seconds for ARP - cache entries. - - ooppttiioonn bboooottffiillee--nnaammee _t_e_x_t;; - - This option is used to identify a bootstrap file. If - supported by the client, it should have the same effect - as the ffiilleennaammee declaration. BOOTP clients are - unlikely to support this option. Some DHCP clients - will support it, and others actually require it. - - ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6;; - - This option specifies the length in 512-octet blocks of - the default boot image for the client. - - ooppttiioonn bbrrooaaddccaasstt--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;; - - This option specifies the broadcast address in use on - the client's subnet. Legal values for broadcast - addresses are specified in section 3.2.1.3 of STD 3 - (RFC1122). - - - - - 2 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - ooppttiioonn ccooookkiiee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The cookie server option specifies a list of RFC 865 - cookie servers available to the client. Servers should - be listed in order of preference. - - ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8_; - - This option specifies the default time-to-live that the - client should use on outgoing datagrams. - - ooppttiioonn ddeeffaauulltt--ttccpp--ttttll _u_i_n_t_8;; - - This option specifies the default TTL that the client - should use when sending TCP segments. The minimum - value is 1. - - ooppttiioonn ddhhccpp--cclliieenntt--iiddeennttiiffiieerr _s_t_r_i_n_g;; - - This option can be used to specify the a DHCP client - identifier in a host declaration, so that dhcpd can - find the host record by matching against the client - identifier. - - ooppttiioonn ddhhccpp--mmaaxx--mmeessssaaggee--ssiizzee _u_i_n_t_1_6;; - - This option, when sent by the client, specifies the - maximum size of any response that the server sends to - the client. When specified on the server, if the - client did not send a dhcp-max-message-size option, the - size specified on the server is used. This works for - BOOTP as well as DHCP responses. - - ooppttiioonn ddhhccpp--ppaarraammeetteerr--rreeqquueesstt--lliisstt _u_i_n_t_1_6;; - - This option, when sent by the client, specifies which - options the client wishes the server to return. Nor­ - mally, in the ISC DHCP client, this is done using the - _r_e_q_u_e_s_t statement. If this option is not specified by - the client, the DHCP server will normally return every - option that is valid in scope and that fits into the - reply. When this option is specified on the server, - the server returns the specified options. This can be - used to force a client to take options that it hasn't - requested, and it can also be used to tailor the - response of the DHCP server for clients that may need a - more limited set of options than those the server would - normally return. - - ooppttiioonn ddoommaaiinn--nnaammee _t_e_x_t;; - - This option specifies the domain name that client - should use when resolving hostnames via the Domain Name - System. - - - - 3 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - ooppttiioonn ddoommaaiinn--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The domain-name-servers option specifies a list of - Domain Name System (STD 13, RFC 1035) name servers - available to the client. Servers should be listed in - order of preference. - - ooppttiioonn eexxtteennssiioonnss--ppaatthh--nnaammee _t_e_x_t;; - - This option specifies the name of a file containing - additional options to be interpreted according to the - DHCP option format as specified in RFC2132. - - ooppttiioonn ffiinnggeerr--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The Finger server option specifies a list of Finger - available to the client. Servers should be listed in - order of preference. - - ooppttiioonn ffoonntt--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - This option specifies a list of X Window System Font - servers available to the client. Servers should be - listed in order of preference. - - ooppttiioonn hhoosstt--nnaammee _s_t_r_i_n_g;; - - This option specifies the name of the client. The name - may or may not be qualified with the local domain name - (it is preferable to use the domain-name option to - specify the domain name). See RFC 1035 for character - set restrictions. - - ooppttiioonn iieeeeee880022--33--eennccaappssuullaattiioonn _f_l_a_g;; - - This option specifies whether or not the client should - use Ethernet Version 2 (RFC 894) or IEEE 802.3 (RFC - 1042) encapsulation if the interface is an Ethernet. A - value of false indicates that the client should use RFC - 894 encapsulation. A value of true means that the - client should use RFC 1042 encapsulation. - - ooppttiioonn iieenn111166--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ]; - - The ien116-name-servers option specifies a list of IEN - 116 name servers available to the client. Servers - should be listed in order of preference. - - ooppttiioonn iimmpprreessss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The impress-server option specifies a list of Imagen - Impress servers available to the client. Servers - should be listed in order of preference. - - - - - 4 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - ooppttiioonn iinntteerrffaaccee--mmttuu _u_i_n_t_1_6;; - - This option specifies the MTU to use on this interface. - The minimum legal value for the MTU is 68. - - ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g;; - - This option specifies whether the client should config­ - ure its IP layer for packet forwarding. A value of - false means disable IP forwarding, and a value of true - means enable IP forwarding. - - ooppttiioonn iirrcc--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The IRC server option specifies a list of IRC available - to the client. Servers should be listed in order of - preference. - - ooppttiioonn lloogg--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The log-server option specifies a list of MIT-LCS UDP - log servers available to the client. Servers should be - listed in order of preference. - - ooppttiioonn llpprr--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The LPR server option specifies a list of RFC 1179 line - printer servers available to the client. Servers - should be listed in order of preference. - - ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g;; - - This option specifies whether or not the client should - respond to subnet mask requests using ICMP. A value of - false indicates that the client should not respond. A - value of true means that the client should respond. - - ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6;; - - This option specifies the maximum size datagram that - the client should be prepared to reassemble. The mini­ - mum value legal value is 576. - - ooppttiioonn mmeerriitt--dduummpp _t_e_x_t;; - - This option specifies the path-name of a file to which - the client's core image should be dumped in the event - the client crashes. The path is formatted as a charac­ - ter string consisting of characters from the NVT ASCII - character set. - - ooppttiioonn mmoobbiillee--iipp--hhoommee--aaggeenntt _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - This option specifies a list of IP addresses indicating - - - - 5 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - mobile IP home agents available to the client. Agents - should be listed in order of preference, although nor­ - mally there will be only one such agent. - - ooppttiioonn nnddss--ccoonntteexxtt _s_t_r_i_n_g;; - - The nds-context option specifies the name of the ini­ - tial Netware Directory Service for an NDS client. - - ooppttiioonn nnddss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The nds-servers option specifies a list of IP addresses - of NDS servers. - - ooppttiioonn nnddss--ttrreeee--nnaammee _s_t_r_i_n_g;; - - The nds-context option specifies NDS tree name that the - NDS client should use. - - ooppttiioonn nneettbbiiooss--dddd--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The NetBIOS datagram distribution server (NBDD) option - specifies a list of RFC 1001/1002 NBDD servers listed - in order of preference. - - ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s...];; - - The NetBIOS name server (NBNS) option specifies a list - of RFC 1001/1002 NBNS name servers listed in order of - preference. NetBIOS Name Service is currently more - commonly referred to as WINS. WINS servers can be - specified using the netbios-name-servers option. - - ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8;; - - The NetBIOS node type option allows NetBIOS over TCP/IP - clients which are configurable to be configured as - described in RFC 1001/1002. The value is specified as - a single octet which identifies the client type. - - Possible node types are: - - - _1 B-node: Broadcast - no WINS - - _2 P-node: Peer - WINS only. - - _4 M-node: Mixed - broadcast, then WINS - - _8 H-node: Hybrid - WINS, then broadcast - - ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g;; - - The NetBIOS scope option specifies the NetBIOS over - - - - 6 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - TCP/IP scope parameter for the client as specified in - RFC 1001/1002. See RFC1001, RFC1002, and RFC1035 for - character-set restrictions. - - ooppttiioonn nnwwiipp--ddoommaaiinn _s_t_r_i_n_g;; - - The name of the NetWare/IP domain that a NetWare/IP - client should use. - - ooppttiioonn nnwwiipp--ssuubbooppttiioonnss _s_t_r_i_n_g;; - - A sequence of suboptions for NetWare/IP clients - see - RFC2242 for details. Normally this option is set by - specifying specific NetWare/IP suboptions - see the - NETWARE/IP SUBOPTIONS section for more information. - - ooppttiioonn nniiss--ddoommaaiinn _t_e_x_t;; - - This option specifies the name of the client's NIS (Sun - Network Information Services) domain. The domain is - formatted as a character string consisting of charac­ - ters from the NVT ASCII character set. - - ooppttiioonn nniiss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - This option specifies a list of IP addresses indicating - NIS servers available to the client. Servers should be - listed in order of preference. - - ooppttiioonn nniisspplluuss--ddoommaaiinn _t_e_x_t;; - - This option specifies the name of the client's NIS+ - domain. The domain is formatted as a character string - consisting of characters from the NVT ASCII character - set. - - ooppttiioonn nniisspplluuss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - This option specifies a list of IP addresses indicating - NIS+ servers available to the client. Servers should - be listed in order of preference. - - ooppttiioonn nnnnttpp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The NNTP server option specifies a list of NNTP avail­ - able to the client. Servers should be listed in order - of preference. - - ooppttiioonn nnoonn--llooccaall--ssoouurrccee--rroouuttiinngg _f_l_a_g;; - - This option specifies whether the client should config­ - ure its IP layer to allow forwarding of datagrams with - non-local source routes (see Section 3.3.5 of [4] for a - discussion of this topic). A value of 0 means disallow - - - - 7 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - forwarding of such datagrams, and a value of true means - allow forwarding. - - ooppttiioonn nnttpp--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - This option specifies a list of IP addresses indicating - NTP (RFC 1035) servers available to the client. - Servers should be listed in order of preference. - - ooppttiioonn ppaatthh--mmttuu--aaggiinngg--ttiimmeeoouutt _u_i_n_t_3_2;; - - This option specifies the timeout (in seconds) to use - when aging Path MTU values discovered by the mechanism - defined in RFC 1191. - - ooppttiioonn ppaatthh--mmttuu--ppllaatteeaauu--ttaabbllee _u_i_n_t_1_6 [,, _u_i_n_t_1_6... ];; - - This option specifies a table of MTU sizes to use when - performing Path MTU Discovery as defined in RFC 1191. - The table is formatted as a list of 16-bit unsigned - integers, ordered from smallest to largest. The mini­ - mum MTU value cannot be smaller than 68. - - ooppttiioonn ppeerrffoorrmm--mmaasskk--ddiissccoovveerryy _f_l_a_g;; - - This option specifies whether or not the client should - perform subnet mask discovery using ICMP. A value of - false indicates that the client should not perform mask - discovery. A value of true means that the client - should perform mask discovery. - - ooppttiioonn ppoolliiccyy--ffiilltteerr _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s - [,, _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s...];; - - This option specifies policy filters for non-local - source routing. The filters consist of a list of IP - addresses and masks which specify destination/mask - pairs with which to filter incoming source routes. - - Any source routed datagram whose next-hop address does - not match one of the filters should be discarded by the - client. - - See STD 3 (RFC1122) for further information. - - ooppttiioonn ppoopp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The POP3 server option specifies a list of POP3 avail­ - able to the client. Servers should be listed in order - of preference. - - ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s - [,, _i_p_-_a_d_d_r_e_s_s...];; - - - - - 8 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - This option specifies a list of RFC 887 Resource Loca­ - tion servers available to the client. Servers should - be listed in order of preference. - - ooppttiioonn rroooott--ppaatthh _t_e_x_t;; - - This option specifies the path-name that contains the - client's root disk. The path is formatted as a charac­ - ter string consisting of characters from the NVT ASCII - character set. - - ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g;; - - This option specifies whether or not the client should - solicit routers using the Router Discovery mechanism - defined in RFC 1256. A value of false indicates that - the client should not perform router discovery. A - value of true means that the client should perform - router discovery. - - ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;; - - This option specifies the address to which the client - should transmit router solicitation requests. - - ooppttiioonn rroouutteerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The routers option specifies a list of IP addresses for - routers on the client's subnet. Routers should be - listed in order of preference. - - ooppttiioonn ssmmttpp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The SMTP server option specifies a list of SMTP servers - available to the client. Servers should be listed in - order of preference. - - ooppttiioonn ssttaattiicc--rroouutteess _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s - [,, _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s...];; - - This option specifies a list of static routes that the - client should install in its routing cache. If multi­ - ple routes to the same destination are specified, they - are listed in descending order of priority. - - The routes consist of a list of IP address pairs. The - first address is the destination address, and the sec­ - ond address is the router for the destination. - - The default route (0.0.0.0) is an illegal destination - for a static route. To specify the default route, use - the rroouutteerrss option. Also, please note that this - option is not intended for classless IP routing - it - does not include a subnet mask. Since classless IP - - - - 9 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - routing is now the most widely deployed routing stan­ - dard, this option is virtually useless, and is not - implemented by any of the popular DHCP clients, for - example the Microsoft DHCP client. - - ooppttiioonn ssttrreeeettttaallkk--ddiirreeccttoorryy--aassssiissttaannccee--sseerrvveerr _i_p_-_a_d_d_r_e_s_s - [,, _i_p_-_a_d_d_r_e_s_s...];; - - The StreetTalk Directory Assistance (STDA) server - option specifies a list of STDA servers available to - the client. Servers should be listed in order of pref­ - erence. - - ooppttiioonn ssttrreeeettttaallkk--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The StreetTalk server option specifies a list of - StreetTalk servers available to the client. Servers - should be listed in order of preference. - - ooppttiioonn ssuubbnneett--mmaasskk _i_p_-_a_d_d_r_e_s_s;; - - The subnet mask option specifies the client's subnet - mask as per RFC 950. If no subnet mask option is pro­ - vided anywhere in scope, as a last resort dhcpd will - use the subnet mask from the subnet declaration for the - network on which an address is being assigned. How­ - ever, _a_n_y subnet-mask option declaration that is in - scope for the address being assigned will override the - subnet mask specified in the subnet declaration. - - ooppttiioonn sswwaapp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s;; - - This specifies the IP address of the client's swap - server. - - ooppttiioonn ttccpp--kkeeeeppaalliivvee--ggaarrbbaaggee _f_l_a_g;; - - This option specifies the whether or not the client - should send TCP keepalive messages with a octet of - garbage for compatibility with older implementations. - A value of false indicates that a garbage octet should - not be sent. A value of true indicates that a garbage - octet should be sent. - - ooppttiioonn ttccpp--kkeeeeppaalliivvee--iinntteerrvvaall _u_i_n_t_3_2;; - - This option specifies the interval (in seconds) that - the client TCP should wait before sending a keepalive - message on a TCP connection. The time is specified as - a 32-bit unsigned integer. A value of zero indicates - that the client should not generate keepalive messages - on connections unless specifically requested by an - application. - - - - - 10 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - ooppttiioonn ttffttpp--sseerrvveerr--nnaammee _t_e_x_t;; - - This option is used to identify a TFTP server and, if - supported by the client, should have the same effect as - the sseerrvveerr--nnaammee declaration. BOOTP clients are - unlikely to support this option. Some DHCP clients - will support it, and others actually require it. - - ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2;; - - The time-offset option specifies the offset of the - client's subnet in seconds from Coordinated Universal - Time (UTC). - - ooppttiioonn ttiimmee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s... ];; - - The time-server option specifies a list of RFC 868 time - servers available to the client. Servers should be - listed in order of preference. - - ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g;; - - This option specifies whether or not the client should - negotiate the use of trailers (RFC 893 [14]) when using - the ARP protocol. A value of 0 indicates that the - client should not attempt to use trailers. A value of - true means that the client should attempt to use trail­ - ers. - - ooppttiioonn uuaapp--sseerrvveerrss _t_e_x_t;; - - This option specifies a list of URLs, each pointing to - a user authentication service that is capable of pro­ - cessing authentication requests encapsulated in the - User Authentication Protocol (UAP). UAP servers can - accept either HTTP 1.1 or SSLv3 connections. If the - list includes a URL that does not contain a port compo­ - nent, the normal default port is assumed (i.e., port 80 - for http and port 443 for https). If the list includes - a URL that does not contain a path component, the path - /uap is assumed. If more than one URL is specified in - this list, the URLs are seperated by spaces. - - ooppttiioonn vveennddoorr--ccllaassss--iiddeennttiiffiieerr _s_t_r_i_n_g;; - - This option is used by some DHCP clients to identify - the vendor type and possibly the configuration of a - DHCP client. The information is a string of bytes - whose contents are specific to the vendor and are not - specified in a standard. To see what vendor class - identifier a clients are sending, you can write the - following in your DHCP server configuration file: - - set vendor-class option vendor-class-identifier; - - - - 11 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - This will result in all entries in the DHCP server - lease database file for clients that sent vendor-class- - identifier options having a set statement that looks - something like this: - - set vendor-class "SUNW.Ultra-5_10"; - - The vendor-class-identifier option is normally used by - the DHCP server to determine the options that are - returned in the vveennddoorr--eennccaappssuullaatteedd--ooppttiioonnss option. - Please see the VENDOR ENCAPSULATED OPTIONS section of - the dhcpd.conf manual page for further information. - - ooppttiioonn vveennddoorr--eennccaappssuullaatteedd--ooppttiioonnss _s_t_r_i_n_g;; - - The vveennddoorr--eennccaappssuullaatteedd--ooppttiioonnss option can contain - either a single vendor-specific value or one or more - vendor-specific suboptions. This option is not nor­ - mally specified in the DHCP server configuration file - - instead, a vendor class is defined for each vendor, - vendor class suboptions are defined, values for those - suboptions are defined, and the DHCP server makes up a - response on that basis. - - Some default behaviours for well-known DHCP client ven­ - dors (currently, the Microsoft Windows 2000 DHCP - client) are configured automatically, but otherwise - this must be configured manually - see the VENDOR - ENCAPSULATED OPTIONS section of the _d_h_c_p_d_._c_o_n_f _m_a_n_u_a_l - _p_a_g_e _f_o_r _d_e_t_a_i_l_s_. - - ooppttiioonn xx--ddiissppllaayy--mmaannaaggeerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - This option specifies a list of systems that are run­ - ning the X Window System Display Manager and are avail­ - able to the client. Addresses should be listed in - order of preference. - - ooppttiioonn wwwwww--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The WWW server option specifies a list of WWW available - to the client. Servers should be listed in order of - preference. - -RREELLAAYY AAGGEENNTT IINNFFOORRMMAATTIIOONN OOPPTTIIOONN - An IETF draft, draft-ietf-dhc-agent-options-03.txt, - defines a series of encapsulated options that a relay - agent can add to a DHCP packet when relaying it to the - DHCP server. The server can then make address allocation - decisions (or whatever other decisions it wants) based on - these options. The server also returns these options in - any replies it sends through the relay agent, so that the - relay agent can use the information in these options for - delivery or accounting purposes. - - - - 12 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - The current draft defines two options. To reference - these options in the dhcp server, specify the option space - name, "agent", followed by a period, followed by the - option name. It isn't useful to specify these options to - be sent, nor is it useful to reference them at all in the - client. - - ooppttiioonn aaggeenntt..cciirrccuuiitt--iidd _s_t_r_i_n_g;; - - The circuit-id suboption encodes an agent-local identi­ - fier 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. - The format of this option is currently defined to be - vendor-dependent, and will probably remain that way, - although the current draft allows for for the possibil­ - ity of standardizing the format in the future. - - ooppttiioonn aaggeenntt..rreemmoottee--iidd _s_t_r_i_n_g;; - - The remote-id suboption encodes information about the - remote host end of a circuit. Examples of what it - might contain include caller ID information, username - information, remote ATM address, cable modem ID, and - similar things. In principal, the meaning is not - well-specified, and it should generally be assumed to - be an opaque object that is administratively guaranteed - to be unique to a particular remote end of a circuit. - -TTHHEE NNEETTWWAARREE//IIPP SSUUBBOOPPTTIIOONNSS - RFC2242 defines a set of encapsulated options for Novell - NetWare/IP clients. To use these options in the dhcp - server, specify the option space name, "nwip", followed by - a period, followed by the option name. The following - options can be specified: - - ooppttiioonn nnwwiipp..nnssqq--bbrrooaaddccaasstt _f_l_a_g;; - - If true, the client should use the NetWare Nearest - Server Query to locate a NetWare/IP server. The - behaviour of the Novell client if this suboption is - false, or is not present, is not specified. - - ooppttiioonn nnwwiipp..pprreeffeerrrreedd--ddssss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - This suboption specifies a list of up to five IP - addresses, each of which should be the IP address of a - NetWare Domain SAP/RIP server (DSS). - - ooppttiioonn nnwwiipp..nneeaarreesstt--nnwwiipp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s - [,, _i_p_-_a_d_d_r_e_s_s...];; - - This suboption specifies a list of up to five IP - addresses, each of which should be the IP address of a - - - - 13 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - Nearest NetWare IP server. - - ooppttiioonn nnwwiipp..aauuttoorreettrriieess _u_i_n_t_8;; - - Specifies the number of times that a NetWare/IP client - should attempt to communicate with a given DSS server - at startup. - - ooppttiioonn nnwwiipp..aauuttoorreettrryy--sseeccss _u_i_n_t_8;; - - Specifies the number of seconds that a Netware/IP - client should wait between retries when attempting to - establish communications with a DSS server at startup. - - ooppttiioonn nnwwiipp..nnwwiipp--11--11 _u_i_n_t_8;; - - If true, the NetWare/IP client should support Net­ - Ware/IP version 1.1 compatibility. This is only - needed if the client will be contacting Netware/IP ver­ - sion 1.1 servers. - - ooppttiioonn nnwwiipp..pprriimmaarryy--ddssss _i_p_-_a_d_d_r_e_s_s;; - - Specifies the IP address of the Primary Domain SAP/RIP - Service server (DSS) for this NetWare/IP domain. The - NetWare/IP administration utility uses this value as - Primary DSS server when configuring a secondary DSS - server. - -DDEEFFIINNIINNGG NNEEWW OOPPTTIIOONNSS - The Internet Software Consortium DHCP client and server - provide the capability to define new options. Each DHCP - option has a name, a code, and a structure. The name is - used by you to refer to the option. The code is a num­ - ber, used by the DHCP server and client to refer to an - option. The structure describes what the contents of an - option looks like. - - To define a new option, you need to choose a name for it - that is not in use for some other option - for example, - you can't use "host-name" because the DHCP protocol - already defines a host-name option, which is documented - earlier in this manual page. If an option name doesn't - appear in this manual page, you can use it, but it's prob­ - ably a good idea to put some kind of unique string at the - beginning so you can be sure that future options don't - take your name. For example, you might define an option, - "local-host-name", feeling some confidence that no offi­ - cial DHCP option name will ever start with "local". - - Once you have chosen a name, you must choose a code. For - site-local options, all codes between 128 and 254 are - reserved for DHCP options, so you can pick any one of - these. In practice, some vendors have interpreted the - - - - 14 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - protocol rather loosely and have used option code values - greater than 128 themselves. There's no real way to - avoid this problem, but it's not likely to cause too much - trouble in practice. - - The structure of an option is simply the format in which - the option data appears. The ISC DHCP server currently - supports a few simple types, like integers, booleans, - strings and IP addresses, and it also supports the ability - to define arrays of single types or arrays of fixed - sequences of types. - - New options are declared as follows: - - ooppttiioonn _n_e_w_-_n_a_m_e ccooddee _n_e_w_-_c_o_d_e == _d_e_f_i_n_i_t_i_o_n ;; - - The values of _n_e_w_-_n_a_m_e and _n_e_w_-_c_o_d_e should be the name you - have chosen for the new option and the code you have cho­ - sen. The _d_e_f_i_n_i_t_i_o_n should be the definition of the - structure of the option. - - The following simple option type definitions are sup­ - ported: - - BBOOOOLLEEAANN - - ooppttiioonn _n_e_w_-_n_a_m_e ccooddee _n_e_w_-_c_o_d_e == bboooolleeaann ;; - - An option of type boolean is a flag with a value of either - on or off (or true or false). So an example use of the - boolean type would be: - - option use-zephyr code 180 = boolean; - option use-zephyr on; - - IINNTTEEGGEERR - - ooppttiioonn _n_e_w_-_n_a_m_e ccooddee _n_e_w_-_c_o_d_e == _s_i_g_n iinntteeggeerr _w_i_d_t_h ;; - - The _s_i_g_n token should either be blank, _u_n_s_i_g_n_e_d or _s_i_g_n_e_d. - The width can be either 8, 16 or 32, and refers to the - number of bits in the integer. So for example, the fol­ - lowing two lines show a definition of the sql-connection- - max option and its use: - - option sql-connection-max code 192 = unsigned integer 16; - option sql-connection-max 1536; - - IIPP--AADDDDRREESSSS - - ooppttiioonn _n_e_w_-_n_a_m_e ccooddee _n_e_w_-_c_o_d_e == iipp--aaddddrreessss ;; - - An option whose structure is an IP address can be - expressed either as a domain name or as a dotted quad. So - - - - 15 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - the following is an example use of the ip-address type: - - option sql-server-address code 193 = ip-address; - option sql-server-address sql.example.com; - - - TTEEXXTT - - ooppttiioonn _n_e_w_-_n_a_m_e ccooddee _n_e_w_-_c_o_d_e == tteexxtt ;; - - An option whose type is text will encode an ASCII text - string. For example: - - option sql-default-connection-name code 194 = text; - option sql-default-connection-name "PRODZA"; - - - DDAATTAA SSTTRRIINNGG - - ooppttiioonn _n_e_w_-_n_a_m_e ccooddee _n_e_w_-_c_o_d_e == ssttrriinngg ;; - - An option whose type is a data string is essentially just - a collection of bytes, and can be specified either as - quoted text, like the text type, or as a list of hexadeci­ - mal contents seperated by colons whose values must be - between 0 and FF. For example: - - option sql-identification-token code 195 = string; - option sql-identification-token 17:23:19:a6:42:ea:99:7c:22; - - - AARRRRAAYYSS - - Options can contain arrays of any of the above types - except for the text and data string types, which aren't - currently supported in arrays. An example of an array - definition is as follows: - - option kerberos-servers code 200 = array of ip-address; - option kerberos-servers 10.20.10.1, 10.20.11.1; - - RREECCOORRDDSS - - Options can also contain data structures consisting of a - sequence of data types, which is sometimes called a record - type. For example: - - option contrived-001 code 201 = { boolean, integer 32, text }; - option contrived-001 on 1772 "contrivance"; - - It's also possible to have options that are arrays of - records, for example: - - option new-static-routes code 201 = array of { - - - - 16 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - ip-address, ip-address, ip-address, integer 8 }; - option static-routes - 10.0.0.0 255.255.255.0 net-0-rtr.example.com 1, - 10.0.1.0 255.255.255.0 net-1-rtr.example.com 1, - 10.2.0.0 255.255.224.0 net-2-0-rtr.example.com 3; - - -VVEENNDDOORR EENNCCAAPPSSUULLAATTEEDD OOPPTTIIOONNSS - The DHCP protocol defines the vveennddoorr--eennccaappssuullaatteedd--ooppttiioonnss - option, which allows vendors to define their own options - that will be sent encapsulated in a standard DHCP option. - The format of the vveennddoorr--eennccaappssuullaatteedd--ooppttiioonnss option is - either a series of bytes whose format is not specified, or - a sequence of options, each of which consists of a single- - byte vendor-specific option code, followed by a single- - byte length, followed by as many bytes of data as are - specified in the length (the length does not include - itself or the option code). - - The value of this option can be set in one of two ways. - The first way is to simply specify the data directly, - using a text string or a colon-seperated list of hexadeci­ - mal values. For example: - - option vendor-encapsulated-options - 2:4:AC:11:41:1: - 3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31: - 4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63; - - The second way of setting the value of this option is to - have the DHCP server generate a vendor-specific option - buffer. To do this, you must do four things: define an - option space, define some options in that option space, - provide values for them, and specify that that option - space should be used to generate the vveennddoorr--eennccaappssuullaatteedd-- - ooppttiioonnss option. - - To define a new option space in which vendor options can - be stored, use the option space statement: - - ooppttiioonn ssppaaccee _n_a_m_e ;; - - The name can then be used in option definitions, as - described earlier in this document. For example: - - option space SUNW; - option SUNW.server-address code 2 = ip-address; - option SUNW.server-name code 3 = text; - option SUNW.root-path code 4 = text; - - Once you have defined an option space and the format of - some options, you can set up scopes that define values for - those options, and you can say when to use them. For - example, suppose you want to handle two different classes - - - - 17 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - of clients. Using the option space definition shown in - the previous example, you can send different option values - to different clients based on the vendor-class-identifier - option that the clients send, as follows: - - class "vendor-classes" { - match option vendor-class-identifier; - } - - option SUNW.server-address 172.17.65.1; - option SUNW.server-name "sundhcp-server17-1"; - - subclass "vendor-classes" "SUNW.Ultra-5_10" { - vendor-option-space SUNW; - option SUNW.root-path "/export/root/sparc"; - } - - subclass "vendor-classes" "SUNW.i86pc" { - vendor-option-space SUNW; - option SUNW.root-path "/export/root/i86pc"; - } - - As you can see in the preceding example, regular scoping - rules apply, so you can define values that are global in - the global scope, and only define values that are specific - to a particular class in the local scope. The vveennddoorr-- - ooppttiioonn--ssppaaccee declaration tells the DHCP server to use - options in the SUNW option space to construct the vveennddoorr-- - eennccaappssuullaatteedd--ooppttiioonnss option. - -SSEEEE AALLSSOO - dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp- - eval(5), dhcpd(8), dhclient(8), RFC2132, RFC2131, draft- - ietf-dhc-agent-options-??.txt. - -AAUUTTHHOORR - The Internet Software Consortium DHCP Distribution was - written by Ted Lemon under a contract - with Vixie Labs. Funding for this project was provided - through the Internet Software Consortium. Information - about the Internet Software Consortium can be found at - hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - - 18 - - diff --git a/server/dhcpd.cat8 b/server/dhcpd.cat8 deleted file mode 100644 index 282efe639..000000000 --- a/server/dhcpd.cat8 +++ /dev/null @@ -1,396 +0,0 @@ - - - -dhcpd(8) dhcpd(8) - - -NNAAMMEE - dhcpd - Dynamic Host Configuration Protocol Server - -SSYYNNOOPPSSIISS - ddhhccppdd [ --pp _p_o_r_t ] [ --ff ] [ --dd ] [ --qq ] [ --tt | --TT ] [ --ccff - _c_o_n_f_i_g_-_f_i_l_e ] [ --llff _l_e_a_s_e_-_f_i_l_e ] [ _i_f_0 [ _._._._i_f_N ] ] - -DDEESSCCRRIIPPTTIIOONN - The Internet Software Consortium DHCP Server, dhcpd, - implements the Dynamic Host Configuration Protocol (DHCP) - and the Internet Bootstrap Protocol (BOOTP). DHCP allows - hosts on a TCP/IP network to request and be assigned IP - addresses, and also to discover information about the net­ - work to which they are attached. BOOTP provides similar - functionality, with certain restrictions. - -CCOONNTTRRIIBBUUTTIIOONNSS - Development of this software is funded through contribu­ - tions and support contracts. Please see ddhhccpp--ccoonnttrriibb((55)) - for information on how you can contribute. - -OOPPEERRAATTIIOONN - The DHCP protocol allows a host which is unknown to the - network administrator to be automatically assigned a new - IP address out of a pool of IP addresses for its network. - In order for this to work, the network administrator allo­ - cates address pools in each subnet and enters them into - the dhcpd.conf(5) file. - - On startup, dhcpd reads the _d_h_c_p_d_._c_o_n_f file and stores a - list of available addresses on each subnet in memory. - When a client requests an address using the DHCP protocol, - dhcpd allocates an address for it. Each client is - assigned a lease, which expires after an amount of time - chosen by the administrator (by default, one day). Before - leases expire, the clients to which leases are assigned - are expected to renew them in order to continue to use the - addresses. Once a lease has expired, the client to which - that lease was assigned is no longer permitted to use the - leased IP address. - - In order to keep track of leases across system reboots and - server restarts, dhcpd keeps a list of leases it has - assigned in the dhcpd.leases(5) file. Before dhcpd - grants a lease to a host, it records the lease in this - file and makes sure that the contents of the file are - flushed to disk. This ensures that even in the event of - a system crash, dhcpd will not forget about a lease that - it has assigned. On startup, after reading the - dhcpd.conf file, dhcpd reads the dhcpd.leases file to - refresh its memory about what leases have been assigned. - - New leases are appended to the end of the dhcpd.leases - file. In order to prevent the file from becoming - - - - 1 - - - - - -dhcpd(8) dhcpd(8) - - - arbitrarily large, from time to time dhcpd creates a new - dhcpd.leases file from its in-core lease database. Once - this file has been written to disk, the old file is - renamed _d_h_c_p_d_._l_e_a_s_e_s_~, and the new file is renamed - dhcpd.leases. If the system crashes in the middle of - this process, whichever dhcpd.leases file remains will - contain all the lease information, so there is no need for - a special crash recovery process. - - BOOTP support is also provided by this server. Unlike - DHCP, the BOOTP protocol does not provide a protocol for - recovering dynamically-assigned addresses once they are no - longer needed. It is still possible to dynamically - assign addresses to BOOTP clients, but some administrative - process for reclaiming addresses is required. By - default, leases are granted to BOOTP clients in perpetu­ - ity, although the network administrator may set an earlier - cutoff date or a shorter lease length for BOOTP leases if - that makes sense. - - BOOTP clients may also be served in the old standard way, - which is to simply provide a declaration in the dhcpd.conf - file for each BOOTP client, permanently assigning an - address to each client. - - Whenever changes are made to the dhcpd.conf file, dhcpd - must be restarted. To restart dhcpd, send a SIGTERM - (signal 15) to the process ID contained in - _/_v_a_r_/_r_u_n_/_d_h_c_p_d_._p_i_d, and then re-invoke dhcpd. Because the - DHCP server database is not as lightweight as a BOOTP - database, dhcpd does not automatically restart itself when - it sees a change to the dhcpd.conf file. - - Note: We get a lot of complaints about this. We realize - that it would be nice if one could send a SIGHUP to the - server and have it reload the database. This is not - technically impossible, but it would require a great deal - of work, our resources are extremely limited, and they can - be better spent elsewhere. So please don't complain - about this on the mailing list unless you're prepared to - fund a project to implement this feature, or prepared to - do it yourself. - -CCOOMMMMAANNDD LLIINNEE - The names of the network interfaces on which dhcpd should - listen for broadcasts may be specified on the command - line. This should be done on systems where dhcpd is - unable to identify non-broadcast interfaces, but should - not be required on other systems. If no interface names - are specified on the command line dhcpd will identify all - network interfaces which are up, elimininating non-broad­ - cast interfaces if possible, and listen for DHCP broad­ - casts on each interface. - - - - - 2 - - - - - -dhcpd(8) dhcpd(8) - - - If dhcpd should listen on a port other than the standard - (port 67), the --pp flag may used. It should be followed by - the udp port number on which dhcpd should listen. This is - mostly useful for debugging purposes. - - To run dhcpd as a foreground process, rather than allowing - it to run as a daemon in the background, the --ff flag - should be specified. This is useful when running dhcpd - under a debugger, or when running it out of inittab on - System V systems. - - To have dhcpd log to the standard error descriptor, spec­ - ify the --dd flag. This can be useful for debugging, and - also at sites where a complete log of all dhcp activity - must be kept but syslogd is not reliable or otherwise can­ - not be used. Normally, dhcpd will log all output using - the syslog(3) function with the log facility set to - LOG_DAEMON. - - Dhcpd can be made to use an alternate configuration file - with the --ccff flag, or an alternate lease file with the --llff - flag. Because of the importance of using the same lease - database at all times when running dhcpd in production, - these options should be used oonnllyy for testing lease files - or database files in a non-production environment. - - When starting dhcpd up from a system startup script (e.g., - /etc/rc), it may not be desirable to print out the entire - copyright message on startup. To avoid printing this - message, the --qq flag may be specified. - - The DHCP server reads two files on startup: a configura­ - tion file, and a lease database. If the --tt flag is spec­ - ified, the server will simply test the configuration file - for correct syntax, but will not attempt to perform any - network operations. This can be used to test the a new - configuration file automatically before installing it. - - The --TT flag can be used to test the lease database file in - a similar way. - -CCOONNFFIIGGUURRAATTIIOONN - The syntax of the dhcpd.conf(5) file is discussed seper­ - ately. This section should be used as an overview of the - configuration process, and the dhcpd.conf(5) documentation - should be consulted for detailed reference information. - - -SSuubbnneettss - dhcpd needs to know the subnet numbers and netmasks of all - subnets for which it will be providing service. In addi­ - tion, in order to dynamically allocate addresses, it must - be assigned one or more ranges of addresses on each subnet - which it can in turn assign to client hosts as they boot. - - - - 3 - - - - - -dhcpd(8) dhcpd(8) - - - Thus, a very simple configuration providing DHCP support - might look like this: - - subnet 239.252.197.0 netmask 255.255.255.0 { - range 239.252.197.10 239.252.197.250; - } - - Multiple address ranges may be specified like this: - - subnet 239.252.197.0 netmask 255.255.255.0 { - range 239.252.197.10 239.252.197.107; - range 239.252.197.113 239.252.197.250; - } - - If a subnet will only be provided with BOOTP service and - no dynamic address assignment, the range clause can be - left out entirely, but the subnet statement must appear. - - -LLeeaassee LLeennggtthhss - DHCP leases can be assigned almost any length from zero - seconds to infinity. What lease length makes sense for - any given subnet, or for any given installation, will vary - depending on the kinds of hosts being served. - - For example, in an office environment where systems are - added from time to time and removed from time to time, but - move relatively infrequently, it might make sense to allow - lease times of a month of more. In a final test environ­ - ment on a manufacturing floor, it may make more sense to - assign a maximum lease length of 30 minutes - enough time - to go through a simple test procedure on a network appli­ - ance before packaging it up for delivery. - - It is possible to specify two lease lengths: the default - length that will be assigned if a client doesn't ask for - any particular lease length, and a maximum lease length. - These are specified as clauses to the subnet command: - - subnet 239.252.197.0 netmask 255.255.255.0 { - range 239.252.197.10 239.252.197.107; - default-lease-time 600; - max-lease-time 7200; - | - - This particular subnet declaration specifies a default - lease time of 600 seconds (ten minutes), and a maximum - lease time of 7200 seconds (two hours). Other common - values would be 86400 (one day), 604800 (one week) and - 2592000 (30 days). - - Each subnet need not have the same lease--in the case of - an office environment and a manufacturing environment - served by the same DHCP server, it might make sense to - - - - 4 - - - - - -dhcpd(8) dhcpd(8) - - - have widely disparate values for default and maximum lease - times on each subnet. - -BBOOOOTTPP SSuuppppoorrtt - Each BOOTP client must be explicitly declared in the - dhcpd.conf file. A very basic client declaration will - specify the client network interface's hardware address - and the IP address to assign to that client. If the - client needs to be able to load a boot file from the - server, that file's name must be specified. A simple - bootp client declaration might look like this: - - host haagen { - hardware ethernet 08:00:2b:4c:59:23; - fixed-address 239.252.197.9; - filename "/tftpboot/haagen.boot"; - } - -OOppttiioonnss - DHCP (and also BOOTP with Vendor Extensions) provide a - mechanism whereby the server can provide the client with - information about how to configure its network interface - (e.g., subnet mask), and also how the client can access - various network services (e.g., DNS, IP routers, and so - on). - - These options can be specified on a per-subnet basis, and, - for BOOTP clients, also on a per-client basis. In the - event that a BOOTP client declaration specifies options - that are also specified in its subnet declaration, the - options specified in the client declaration take prece­ - dence. An reasonably complete DHCP configuration might - look something like this: - - subnet 239.252.197.0 netmask 255.255.255.0 { - range 239.252.197.10 239.252.197.250; - default-lease-time 600 max-lease-time 7200; - option subnet-mask 255.255.255.0; - option broadcast-address 239.252.197.255; - option routers 239.252.197.1; - option domain-name-servers 239.252.197.2, 239.252.197.3; - option domain-name "isc.org"; - } - - A bootp host on that subnet that needs to be in a differ­ - ent domain and use a different name server might be - declared as follows: - - host haagen { - hardware ethernet 08:00:2b:4c:59:23; - fixed-address 239.252.197.9; - filename "/tftpboot/haagen.boot"; - option domain-name-servers 192.5.5.1; - option domain-name "vix.com"; - - - - 5 - - - - - -dhcpd(8) dhcpd(8) - - - } - - A more complete description of the dhcpd.conf file syntax - is provided in dhcpd.conf(5). - -FFIILLEESS - //eettcc//ddhhccppdd..ccoonnff,, //vvaarr//ddbb//ddhhccppdd..lleeaasseess,, //vvaarr//rruunn//ddhhccppdd..ppiidd,, - //vvaarr//ddbb//ddhhccppdd..lleeaasseess~~.. - -SSEEEE AALLSSOO - dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5) - -AAUUTTHHOORR - ddhhccppdd((88)) was written by Ted Lemon under a - contract with Vixie Labs. Funding for this project was - provided by the Internet Software Consortium. Information - about the Internet Software Consortium can be found at - hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6 - - diff --git a/server/dhcpd.conf.cat5 b/server/dhcpd.conf.cat5 deleted file mode 100644 index f104d6350..000000000 --- a/server/dhcpd.conf.cat5 +++ /dev/null @@ -1,1716 +0,0 @@ - - - -dhcpd.conf(5) dhcpd.conf(5) - - -NNAAMMEE - dhcpd.conf - dhcpd configuration file - -DDEESSCCRRIIPPTTIIOONN - The dhcpd.conf file contains configuration information for - _d_h_c_p_d_, the Internet Software Consortium DHCP Server. - - The dhcpd.conf file is a free-form ASCII text file. It - is parsed by the recursive-descent parser built into - dhcpd. The file may contain extra tabs and newlines for - formatting purposes. Keywords in the file are case-insen­ - sitive. Comments may be placed anywhere within the file - (except within quotes). Comments begin with the # char­ - acter and end at the end of the line. - - The file essentially consists of a list of statements. - Statements fall into two broad categories - parameters and - declarations. - - Parameter statements either say how to do something (e.g., - how long a lease to offer), whether to do something (e.g., - should dhcpd provide addresses to unknown clients), or - what parameters to provide to the client (e.g., use gate­ - way 220.177.244.7). - - Declarations are used to describe the topology of the net­ - work, to describe clients on the network, to provide - addresses that can be assigned to clients, or to apply a - group of parameters to a group of declarations. In any - group of parameters and declarations, all parameters must - be specified before any declarations which depend on those - parameters may be specified. - - Declarations about network topology include the - _s_h_a_r_e_d_-_n_e_t_w_o_r_k and the _s_u_b_n_e_t declarations. If clients - on a subnet are to be assigned addresses dynamically, a - _r_a_n_g_e declaration must appear within the _s_u_b_n_e_t declara­ - tion. For clients with statically assigned addresses, or - for installations where only known clients will be served, - each such client must have a _h_o_s_t declaration. If param­ - eters are to be applied to a group of declarations which - are not related strictly on a per-subnet basis, the _g_r_o_u_p - declaration can be used. - - For every subnet which will be served, and for every sub­ - net to which the dhcp server is connected, there must be - one _s_u_b_n_e_t declaration, which tells dhcpd how to recognize - that an address is on that subnet. A _s_u_b_n_e_t declaration - is required for each subnet even if no addresses will be - dynamically allocated on that subnet. - - Some installations have physical networks on which more - than one IP subnet operates. For example, if there is a - site-wide requirement that 8-bit subnet masks be used, but - - - - 1 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - a department with a single physical ethernet network - expands to the point where it has more than 254 nodes, it - may be necessary to run two 8-bit subnets on the same eth­ - ernet until such time as a new physical network can be - added. In this case, the _s_u_b_n_e_t declarations for these - two networks may be enclosed in a _s_h_a_r_e_d_-_n_e_t_w_o_r_k declara­ - tion. - - Some sites may have departments which have clients on more - than one subnet, but it may be desirable to offer those - clients a uniform set of parameters which are different - than what would be offered to clients from other depart­ - ments on the same subnet. For clients which will be - declared explicitly with _h_o_s_t declarations, these declara­ - tions can be enclosed in a _g_r_o_u_p declaration along with - the parameters which are common to that department. For - clients whose addresses will be dynamically assigned, - class declarations and conditional declarations may be - used to group parameter assignments based on information - the client sends. - - When a client is to be booted, its boot parameters are - determined by consulting that client's _h_o_s_t declaration - (if any), and then consulting the any _c_l_a_s_s declarations - matching the client, followed by the _p_o_o_l, _s_u_b_n_e_t and - _s_h_a_r_e_d_-_n_e_t_w_o_r_k declarations for the IP address assigned to - the client. Each of these declarations itself appears - within a lexical scope, and all declarations at less spe­ - cific lexical scopes are also consulted for client option - declarations as well. Scopes are never considered twice, - and if parameters are declared in more than one scope, the - parameter declared in the most specific scope is the one - that is used. - - When dhcpd tries to find a _h_o_s_t declaration for a client, - it first looks for a _h_o_s_t declaration which has a _f_i_x_e_d_- - _a_d_d_r_e_s_s parameter which matches the subnet or shared net­ - work on which the client is booting. If it doesn't find - any such entry, it then tries to find an entry which has - no _f_i_x_e_d_-_a_d_d_r_e_s_s parameter. If no such entry is found, - then dhcpd acts as if there is no entry in the dhcpd.conf - file for that client, even if there is an entry for that - client on a different subnet or shared network. - -EEXXAAMMPPLLEESS - A typical dhcpd.conf file will look something like this: - - _g_l_o_b_a_l _p_a_r_a_m_e_t_e_r_s_._._. - - subnet 204.254.239.0 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.10 204.254.239.30; - } - - - - - 2 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - subnet 204.254.239.32 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.42 204.254.239.62; - } - - subnet 204.254.239.64 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.74 204.254.239.94; - } - - group { - _g_r_o_u_p_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - host zappo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - host beppo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - host harpo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - } - - Figure 1 - - - Notice that at the beginning of the file, there's a place - for global parameters. These might be things like the - organization's domain name, the addresses of the name - servers (if they are common to the entire organization), - and so on. So, for example: - - option domain-name "isc.org"; - option domain-name-servers ns1.isc.org, ns2.isc.org; - - Figure 2 - - As you can see in Figure 2, you can specify host addresses - in parameters using their domain names rather than their - numeric IP addresses. If a given hostname resolves to - more than one IP address (for example, if that host has - two ethernet interfaces), then where possible, both - addresses are supplied to the client. - - The most obvious reason for having subnet-specific parame­ - ters as shown in Figure 1 is that each subnet, of neces­ - sity, has its own router. So for the first subnet, for - example, there should be something like: - - option routers 204.254.239.1; - - Note that the address here is specified numerically. - This is not required - if you have a different domain name - for each interface on your router, it's perfectly - - - - 3 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - legitimate to use the domain name for that interface - instead of the numeric address. However, in many cases - there may be only one domain name for all of a router's IP - addresses, and it would not be appropriate to use that - name here. - - In Figure 1 there is also a _g_r_o_u_p statement, which pro­ - vides common parameters for a set of three hosts - zappo, - beppo and harpo. As you can see, these hosts are all in - the test.isc.org domain, so it might make sense for a - group-specific parameter to override the domain name sup­ - plied to these hosts: - - option domain-name "test.isc.org"; - - Also, given the domain they're in, these are probably test - machines. If we wanted to test the DHCP leasing mecha­ - nism, we might set the lease timeout somewhat shorter than - the default: - - max-lease-time 120; - default-lease-time 120; - - You may have noticed that while some parameters start with - the _o_p_t_i_o_n keyword, some do not. Parameters starting - with the _o_p_t_i_o_n keyword correspond to actual DHCP options, - while parameters that do not start with the option keyword - either control the behaviour of the DHCP server (e.g., how - long a lease dhcpd will give out), or specify client - parameters that are not optional in the DHCP protocol (for - example, server-name and filename). - - In Figure 1, each host had _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s. - These could include such things as the _h_o_s_t_n_a_m_e option, - the name of a file to upload (the _f_i_l_e_n_a_m_e _p_a_r_a_m_e_t_e_r_) _a_n_d - _t_h_e _a_d_d_r_e_s_s _o_f _t_h_e _s_e_r_v_e_r _f_r_o_m _w_h_i_c_h _t_o _u_p_l_o_a_d _t_h_e _f_i_l_e - _(_t_h_e _n_e_x_t_-_s_e_r_v_e_r parameter). In general, any parameter - can appear anywhere that parameters are allowed, and will - be applied according to the scope in which the parameter - appears. - - Imagine that you have a site with a lot of NCD X-Termi­ - nals. These terminals come in a variety of models, and - you want to specify the boot files for each models. One - way to do this would be to have host declarations for each - server and group them by model: - - group { - filename "Xncd19r"; - next-server ncd-booter; - - host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; } - host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; } - host ncd8 { hardware ethernet 0:c0:c3:22:46:81; } - - - - 4 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - } - - group { - filename "Xncd19c"; - next-server ncd-booter; - - host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; } - host ncd3 { hardware ethernet 0:c0:c3:00:14:11; } - } - - group { - filename "XncdHMX"; - next-server ncd-booter; - - host ncd1 { hardware ethernet 0:c0:c3:11:90:23; } - host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; } - host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; } - } - -AADDDDRREESSSS PPOOOOLLSS - The ppooooll declaration can be used to specify a pool of - addresses that will be treated differently than another - pool of addresses, even on the same network segment or - subnet. For example, you may want to provide a large set - of addresses that can be assigned to DHCP clients that are - registered to your DHCP server, while providing a smaller - set of addresses, possibly with short lease times, that - are available for unknown clients. If you have a fire­ - wall, you may be able to arrange for addresses from one - pool to be allowed access to the Internet, while addresses - in another pool are not, thus encouraging users to regis­ - ter their DHCP clients. To do this, you would set up a - pair of pool declarations: - - subnet 10.0.0.0 netmask 255.255.255.0 { - option routers 10.0.0.254; - - # Unknown clients get this pool. - pool { - option domain-name-servers bogus.example.com; - max-lease-time 300; - range 10.0.0.200 10.0.0.253; - allow unknown clients; - } - - # Known clients get this pool. - pool { - option domain-name-servers ns1.example.com, ns2.example.com; - max-lease-time 28800; - range 10.0.0.5 10.0.0.199; - deny unknown clients; - } - } - - - - - 5 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - It is also possible to set up entirely different subnets - for known and unknown clients - address pools exist at the - level of shared networks, so address ranges within pool - declarations can be on different subnets. - - As you can see in the preceding example, pools can have - permit lists that control which clients are allowed access - to the pool and which aren't. Each entry in a pool's per­ - mit list is introduced with the _a_l_l_o_w or _d_e_n_y keyword. - If a pool has a permit list, then only those clients that - match specific entries on the permit list will be elegible - to be assigned addresses from the pool. If a pool has a - deny list, then only those clients that do not match any - entries on the deny list will be elegible. If both per­ - mit and deny lists exist for a pool, then only clients - that match the permit list and do not match the deny list - will be allowed access. - -AADDDDRREESSSS AALLLLOOCCAATTIIOONN - Address allocation is actually only done when a client is - in the INIT state and has sent a DHCPDISCOVER message. If - the client thinks it has a valid lease and sends a DHCPRE­ - QUEST to initiate or renew that lease, the server has only - three choices - it can ignore the DHCPREQUEST, send a - DHCPNAK to tell the client it should stop using the - address, or send a DHCPACK, telling the client to go ahead - and use the address for a while. If the server finds the - address the client is requesting, and that address is - available to the client, the server will send a DHCPACK. - If the address is no longer available, or the client isn't - permitted to have it, the server will send a DHCPNAK. If - the server knows nothing about the, it will remain silent, - unless the address is incorrect for the network segment to - which the client has been attached and the server is - authoritative for that network segment, in which case the - server will send a DHCPNAK even though it doesn't know - about the address. - - When the DHCP server allocates a new address for a client - (remember, this only happens if the client has sent a - DHCPDISCOVER), it first looks to see if the client already - has a valid lease on an IP address, or if there is an old - IP address the client had before that hasn't yet been - reassigned. In that case, the server will take that - address and check it to see if the client is still permit­ - ted to use it. If the client is no longer permitted to - use it, the lease is freed if the server thought it was - still in use - the fact that the client has sent a - DHCPDISCOVER proves to the server that the client is no - longer using the lease. - - If no existing lease is found, or if the client is forbid­ - den to receive the existing lease, then the server will - look in the list of address pools for the network segment - - - - 6 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - to which the client is attached for a lease that is not in - use and that the client is permitted to have. It looks - through each pool declaration in sequence (all _r_a_n_g_e dec­ - larations that appear outside of pool declarations are - grouped into a single pool with no permit list). If the - permit list for the pool allows the client to be allocated - an address from that pool, the pool is examined to see if - there is an address available. If so, then the client is - tentatively assigned that address. Otherwise, the next - pool is tested. If no addresses are found that can be - assigned to the client, no response is sent to the client. - - If an address is found that the client is permitted to - have, and that has never been assigned to any client - before, the address is immediately allocated to the - client. If the address is available for allocation but - has been previously assigned to a different client, the - server will keep looking in hopes of finding an address - that has never before been assigned to a client. - -CCLLIIEENNTT CCLLAASSSSIINNGG - Clients can be seperated into classes, and treated differ­ - ently depending on what class they are in. This sepera­ - tion can be done either with a conditional statement, or - with a match statement within the class declaration. It - is possible to specify a limit on the total number of - clients within a particular class or subclass that may - hold leases at one time, and it is possible to specify - automatic subclassing based on the contents of the client - packet. - - To add clients to classes based on conditional evaluation, - you would write an conditional statement to match the - clients you wanted in the class, and then put an aadddd - statement in the conditional's list of statements: - - if substring (option dhcp-client-identifier, 0, 3) = "RAS" { - add "ras-clients"; - } - - A nearly equivalent way to do this is to simply specify - the conditional expression as a matching expression in the - class statement: - - class "ras-clients" { - match if substring (option dhcp-client-identifier, 0, 3) = "RAS"; - } - Note that whether you use matching expressions or add - statements (or both) to classify clients, you must always - write a class declaration for any class that you use. If - there will be no match statement and no in-scope state­ - ments for a class, the declaration should look like this: - class "ras-clients" { - } - - - - 7 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - Also, the aadddd statement adds the client to the class as - the client's scopes are being evaluated - after any - address assignment decision has been made. This means - that a client that's a member of a class due to an add - statement will not be affected by pool permits related to - that class - when the pool permit list is computed, the - client will not yet be a member of the pool. This is an - inconsistency that will probably be addressed in later - versions of the DHCP server, but it important to be aware - of it at lease for the time being. - -SSUUBBCCLLAASSSSEESS - In addition to classes, it is possible to declare sub­ - classes. A subclass is a class with the same name as a - regular class, but with a specific submatch expression - which is hashed for quick matching. This is essentially a - speed hack - the main difference between five classes with - match expressions and one class with five subclasses is - that it will be quicker to find the subclasses. Sub­ - classes work as follows: - - class "allocation-class-1" { - match pick-first-value (option dhcp-client-identifier, hardware); - } - - class "allocation-class-2" { - match pick-first-value (option dhcp-client-identifier, hardware); - } - - subclass "allocation-class-1" 1:8:0:2b:4c:39:ad; - subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3; - subclass "allocation-class-1" 1:0:0:c4:aa:29:44; - - subnet 10.0.0.0 netmask 255.255.255.0 { - pool { - allow members of "allocation-class-1"; - range 10.0.0.11 10.0.0.50; - } - pool { - allow members of "allocation-class-2"; - range 10.0.0.51 10.0.0.100; - } - } - - The data following the class name in the subclass declara­ - tion is a constant value to use in matching the match - expression for the class. When class matching is done, - the server will evaluate the match expression and then - look the result up in the hash table. If it finds a - match, the client is considered a member of both the class - and the subclass. - - Subclasses can be declared with or without scope. In the - above example, the sole purpose of the subclass is to - - - - 8 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - allow some clients access to one address pool, while other - clients are given access to the other pool, so these sub­ - classes are declared without scopes. If part of the pur­ - pose of the subclass were to define different parameter - values for some clients, you might want to declare some - subclasses with scopes. - - In the above example, if you had a single client that - needed some configuration parameters, while most didn't, - you might write the following subclass declaration for - that client: - - subclass "allocation-class-2" 1:08:00:2b:a1:11:31 { - option root-path "samsara:/var/diskless/alphapc"; - filename "/tftpboot/netbsd.alphapc-diskless"; - } - - In this example, we've used subclassing as a way to con­ - trol address allocation on a per-client basis. However, - it's also possible to use subclassing in ways that are not - specific to clients - for example, to use the value of the - vendor-class-identifier option to determine what values to - send in the vendor-encapsulated-options option. An exam­ - ple of this is shown under the VENDOR ENCAPSULATED OPTIONS - head later on in this document. - -PPEERR--CCLLAASSSS LLIIMMIITTSS OONN DDYYNNAAMMIICC AADDDDRREESSSS AALLLLOOCCAATTIIOONN - You may specify a limit to the number of clients in a - class that can be assigned leases. The effect of this - will be to make it difficult for a new client in a class - to get an address. Once a class with such a limit has - reached its limit, the only way a new client in that class - can get a lease is for an existing client to relinquish - its lease, either by letting it expire, or by sending a - DHCPRELEASE packet. Classes with lease limits are speci­ - fied as follows: - - class "limited-1" { - lease limit 4; - } - - This will produce a class in which a maximum of four mem­ - bers may hold a lease at one time. - -SSPPAAWWNNIINNGG CCLLAASSSSEESS - It is possible to declare a _s_p_a_w_n_i_n_g _c_l_a_s_s. A spawning - class is a class that automatically produces subclasses - based on what the client sends. The reason that spawning - classes were created was to make it possible to create - lease-limited classes on the fly. The envisioned appli­ - cation is a cable-modem environment where the ISP wishes - to provide clients at a particular site with more than one - IP address, but does not wish to provide such clients with - their own subnet, nor give them an unlimited number of IP - - - - 9 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - addresses from the network segment to which they are con­ - nected. - - Many cable modem head-end systems can be configured to add - a Relay Agent Information option to DHCP packets when - relaying them to the DHCP server. These systems typi­ - cally add a circuit ID or remote ID option that uniquely - identifies the customer site. To take advantage of this, - you can write a class declaration as follows: - - class "customer" { - spawn with option agent.circuit-id; - lease limit 4; - } - - Now whenever a request comes in from a customer site, the - circuit ID option will be checked against the class's hash - table. If a subclass is found that matches the circuit - ID, the client will be classified in that subclass and - treated accordingly. If no subclass is found matching - the circuit ID, a new one will be created and logged in - the ddhhccppdd..lleeaasseess file, and the client will be classified - in this new class. Once the client has been classified, - it will be treated according to the rules of the class, - including, in this case, being subject to the per-site - limit of four leases. - - The use of the subclass spawning mechanism is not - restricted to relay agent options - this particular exam­ - ple is given only because it is a fairly straightforward - one. - -DDYYNNAAMMIICC DDNNSS UUPPDDAATTEESS - The DHCP server has the ability to dynamically update the - Domain Name System. Within the configuration files, you - can define how you want the Domain Name System to be - updated. These updates are RFC 2136 compliant so any DNS - server supporting RFC 2136 should be able to accept - updates from the DHCP server. The DHCP server will only - perform DNS updates if it has been built with DNS updates - enabled as described in the README file that comes with - the DHCP distribution. - - The Dynamic DNS update scheme implemented in this version - of the ISC DHCP server is an interim implementation, which - does not implement any of the standard update methods that - have been discussed in the working group, but rather - implements some very basic, yet useful, update capabili­ - ties. - - There are three parameters, which may vary according to - the scope, that control how DDNS updates will be done. - The first two are the _d_d_n_s_-_d_o_m_a_i_n_n_a_m_e and _d_d_n_s_-_r_e_v_-_d_o_m_a_i_n_­ - _n_a_m_e statements. The _d_d_n_s_-_d_o_m_a_i_n_n_a_m_e parameter sets the - - - - 10 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - domain name that will be appended to the client's hostname - to form a fully-qualified domain-name (FQDN). For exam­ - ple, if the client's hostname is "hutson" and the _d_d_n_s_- - _d_o_m_a_i_n_n_a_m_e is set to "sneedville.edu", then the client's - FQDN will be "hutson.sneedville.edu". - - The _d_d_n_s_-_r_e_v_-_d_o_m_a_i_n_n_a_m_e parameter sets the domain name - that will be appended to the client's reversed IP address - to produce a name for use in the client's PTR record. - Normally, you would set this to "in-addr.arpa", but this - is not required. - - A third parameter, _d_d_n_s_-_h_o_s_t_n_a_m_e can be used to specify - the hostname that will be used as the client's hostname. - If no ddns-hostname is specified in scope, then the server - will use a host-name option sent by the client. If the - client did not send a host-name option, then if there is a - host declaration that applies to the client, the name from - that declaration will be used. If none of these applies, - the server will not have a hostname for the client, and - will not be able to do a DDNS update. - -HHOOWW DDNNSS UUPPDDAATTEESS WWOORRKK - The client's FQDN, derived as we have described, is used - as the name on which an "A" record will be stored. The A - record will contain the IP address that the client was - assigned in its lease. If there is already an A record - with the same name in the DNS server, no update of either - the A or PTR records will occur - this prevents a client - from claiming that its hostname is the name of some net­ - work server. For example, if you have a fileserver - called "fs.sneedville.edu", and the client claims its - hostname is "fs", no DNS update will be done for that - client, and an error message will be logged. - - If the A record update succeeds, a PTR record update for - the assigned IP address will be done, pointing to the A - record. This update is unconditional - it will be done - even if another PTR record of the same name exists. - Since the IP address has been assigned to the DHCP server, - this should be safe. - - Please note that the current implementation assumes - clients only have a single network interface. A client - with two network interfaces will see unpredictable - behaviour. This is considered a bug, and will be fixed - in a later release. It may be helpful to enable the _o_n_e_- - _l_e_a_s_e_-_p_e_r_-_c_l_i_e_n_t parameter so that roaming clients do not - trigger this same behavior. - - The DHCP protocol normally involves a four-packet exchange - - first the client sends a DHCPDISCOVER message, then the - server sends a DHCPOFFER, then the client sends a DHCPRE­ - QUEST, then the server sends a DHCPACK. In the current - - - - 11 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - version of the server, the server will do a DNS update - after it has received the DHCPREQUEST, and before it has - sent the DHCPOFFER. It only sends the DNS update if it - has not sent one for the client's address before, in order - to minimize the impact on the DHCP server. - - When the client's lease expires, the DHCP server (if it is - operating at the time, or when next it operates) will - remove the client's A and PTR records from the DNS - database. If the client releases its lease by sending a - DHCPRELEASE message, the server will likewise remove the A - and PTR records. - -DDYYNNAAMMIICC DDNNSS UUPPDDAATTEE SSEECCUURRIITTYY - Support for TSIG and DNSSEC is not yet available. When - you set your DNS server up to allow updates from the DHCP - server, you may be exposing it to unauthorized updates. - To avoid this, the best you can do right now is to use IP - address-based packet filtering to prevent unauthorized - hosts from submitting update requests. - - The DNS server must be configured to allow updates for any - zone that the DHCP server will be updating. For example, - let us say that clients in the sneedville.edu domain will - be assigned addresses on the 10.10.17.0/24 subnet. In - that case, assuming you are using ISC BIND 8.2.1 or later, - you would need to have the following declarations in your - /etc/named.conf file: - - zone "sneedville.edu" { - type master; - file "sneedville.edu.db"; - allow-update { localhost; }; - }; - - zone "17.10.10.in-addr.arpa" { - type master; - file "10.10.17.db"; - allow-update { localhost; }; - }; - - This assumes that your DHCP server and your name server - will be running on the same computer - the "localhost" - name is taken in the DNS server as an alias for all of - that host's IP addresses, and updates from any of those - addresses will be accepted. - - You may wish to enable logging of DNS transactions on your - DNS server. To do so, you might write a logging statement - like the following: - - logging { - channel update_debug { - file "/var/log/update-debug.log"; - - - - 12 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - severity debug 3; - print-category yes; - print-severity yes; - print-time yes; - }; - channel security_info { - file "/var/log/named-auth.info"; - severity info; - print-category yes; - print-severity yes; - print-time yes; - }; - - category update { update_debug; }; - category security { security_info; }; - }; - - You must create the /var/log/named-auth.info and - /var/log/update-debug.log files before starting the name - server. For more information on configuring ISC BIND, - consult the documentation that accompanies it. - -RREEFFEERREENNCCEE:: EEVVEENNTTSS - There are three kinds of events that can happen regarding - a lease, and it is possible to declare statements that - occur when any of these events happen. These events are - the commit event, when the server has made a commitment of - a certain lease to a client, the release event, when the - client has released the server from its commitment, and - the expiry event, when the commitment expires. - - To declare a set of statements to execute when an event - happens, you must use the oonn statement, followed by the - name of the event, followed by a series of statements to - execute when the event happens, enclosed in braces. - Events are used to implement dynamic DNS updates, so you - should not define your own event handlers if you are using - the built-in dynamic DNS update mechanism. - -RREEFFEERREENNCCEE:: DDEECCLLAARRAATTIIOONNSS - TThhee _s_h_a_r_e_d_-_n_e_t_w_o_r_k ssttaatteemmeenntt - - sshhaarreedd--nneettwwoorrkk _n_a_m_e {{ - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - The _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement is used to inform the DHCP - server that some IP subnets actually share the same physi­ - cal network. Any subnets in a shared network should be - declared within a _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement. Parameters - specified in the _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement will be used - when booting clients on those subnets unless parameters - provided at the subnet or host level override them. If - - - - 13 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - any subnet in a shared network has addresses available for - dynamic allocation, those addresses are collected into a - common pool for that shared network and assigned to - clients as needed. There is no way to distinguish on - which subnet of a shared network a client should boot. - - _N_a_m_e should be the name of the shared network. This name - is used when printing debugging messages, so it should be - descriptive for the shared network. The name may have - the syntax of a valid domain name (although it will never - be used as such), or it may be any arbitrary name, - enclosed in quotes. - - TThhee _s_u_b_n_e_t ssttaatteemmeenntt - - ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k {{ - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - The _s_u_b_n_e_t statement is used to provide dhcpd with enough - information to tell whether or not an IP address is on - that subnet. It may also be used to provide subnet-spe­ - cific parameters and to specify what addresses may be - dynamically allocated to clients booting on that subnet. - Such addresses are specified using the _r_a_n_g_e declaration. - - The _s_u_b_n_e_t_-_n_u_m_b_e_r should be an IP address or domain name - which resolves to the subnet number of the subnet being - described. The _n_e_t_m_a_s_k should be an IP address or domain - name which resolves to the subnet mask of the subnet being - described. The subnet number, together with the netmask, - are sufficient to determine whether any given IP address - is on the specified subnet. - - Although a netmask must be given with every subnet decla­ - ration, it is recommended that if there is any variance in - subnet masks at a site, a subnet-mask option statement be - used in each subnet declaration to set the desired subnet - mask, since any subnet-mask option statement will override - the subnet mask declared in the subnet statement. - - TThhee _r_a_n_g_e ssttaatteemmeenntt - - rraannggee [ ddyynnaammiicc--bboooottpp ] _l_o_w_-_a_d_d_r_e_s_s [ _h_i_g_h_-_a_d_d_r_e_s_s];; - - For any subnet on which addresses will be assigned dynami­ - cally, there must be at least one _r_a_n_g_e statement. The - range statement gives the lowest and highest IP addresses - in a range. All IP addresses in the range should be in - the subnet in which the _r_a_n_g_e statement is declared. The - _d_y_n_a_m_i_c_-_b_o_o_t_p flag may be specified if addresses in the - specified range may be dynamically assigned to BOOTP - clients as well as DHCP clients. When specifying a - - - - 14 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - single address, _h_i_g_h_-_a_d_d_r_e_s_s can be omitted. - - TThhee _h_o_s_t ssttaatteemmeenntt - - hhoosstt _h_o_s_t_n_a_m_e { - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - There must be at least one hhoosstt statement for every BOOTP - client that is to be served. hhoosstt statements may also be - specified for DHCP clients, although this is not required - unless booting is only enabled for known hosts. - - If it is desirable to be able to boot a DHCP or BOOTP - client on more than one subnet with fixed addresses, more - than one address may be specified in the _f_i_x_e_d_-_a_d_d_r_e_s_s - parameter, or more than one hhoosstt statement may be speci­ - fied. - - If client-specific boot parameters must change based on - the network to which the client is attached, then multiple - hhoosstt statements should be used. - - If a client is to be booted using a fixed address if it's - possible, but should be allocated a dynamic address other­ - wise, then a hhoosstt statement must be specified without a - ffiixxeedd--aaddddrreessss clause. _h_o_s_t_n_a_m_e should be a name identify­ - ing the host. If a _h_o_s_t_n_a_m_e option is not specified for - the host, _h_o_s_t_n_a_m_e is used. - - _H_o_s_t declarations are matched to actual DHCP or BOOTP - clients by matching the dhcp-client-identifier option - specified in the _h_o_s_t declaration to the one supplied by - the client, or, if the _h_o_s_t declaration or the client does - not provide a dhcp-client-identifier option, by matching - the _h_a_r_d_w_a_r_e parameter in the _h_o_s_t declaration to the net­ - work hardware address supplied by the client. BOOTP - clients do not normally provide a _d_h_c_p_-_c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r, - so the hardware address must be used for all clients that - may boot using the BOOTP protocol. - - TThhee _g_r_o_u_p ssttaatteemmeenntt - - ggrroouupp { - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - The group statement is used simply to apply one or more - parameters to a group of declarations. It can be used to - group hosts, shared networks, subnets, or even other - groups. - - - - - 15 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - -RREEFFEERREENNCCEE:: AALLLLOOWW AANNDD DDEENNYY - The _a_l_l_o_w and _d_e_n_y statements can be used to control the - response of the DHCP server to various sorts of requests. - The allow and deny keywords actually have different mean­ - ings depending on the context. In a pool context, these - keywords can be used to set up access lists for address - allocation pools. In other contexts, the keywords simply - control general server behaviour with respect to clients - based on scope. In a non-pool context, the _i_g_n_o_r_e key­ - word can be used in place of the _d_e_n_y keyword to prevent - logging of denied requests. - - -AALLLLOOWW DDEENNYY AANNDD IIGGNNOORREE IINN SSCCOOPPEE - The following usages of allow and deny will work in any - scope, although it is not recommended that they be used in - pool declarations. - - TThhee _u_n_k_n_o_w_n_-_c_l_i_e_n_t_s kkeeyywwoorrdd - - aallllooww uunnkknnoowwnn--cclliieennttss;; - ddeennyy uunnkknnoowwnn--cclliieennttss;; - iiggnnoorree uunnkknnoowwnn--cclliieennttss;; - - The uunnkknnoowwnn--cclliieennttss flag is used to tell dhcpd whether or - not to dynamically assign addresses to unknown clients. - Dynamic address assignment to unknown clients is aalllloowwed - by default. - - TThhee _b_o_o_t_p kkeeyywwoorrdd - - aallllooww bboooottpp;; - ddeennyy bboooottpp;; - iiggnnoorree bboooottpp;; - - The bboooottpp flag is used to tell dhcpd whether or not to - respond to bootp queries. Bootp queries are aalllloowwed by - default. - - TThhee _b_o_o_t_i_n_g kkeeyywwoorrdd - - aallllooww bboooottiinngg;; - ddeennyy bboooottiinngg;; - iiggnnoorree bboooottiinngg;; - - The bboooottiinngg flag is used to tell dhcpd whether or not to - respond to queries from a particular client. This keyword - only has meaning when it appears in a host declaration. - By default, booting is aalllloowwed, but if it is disabled for - a particular client, then that client will not be able to - get and address from the DHCP server. TThhee _d_u_p_l_i_c_a_t_e_s kkeeyy­­ - wwoorrdd - - aallllooww dduupplliiccaatteess;; - - - - 16 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - ddeennyy dduupplliiccaatteess;; - - Host declarations can match client messages based on the - DHCP Client Identifer option or based on the client's net­ - work hardware type and MAC address. If the MAC address - is used, the host declaration will match any client with - that MAC address - even clients with different client - identifiers. This doesn't normally happen, but is possi­ - ble when one computer has more than one operating system - installed on it - for example, Microsoft Windows and - NetBSD or Linux. - - The dduupplliiccaatteess flag tells the DHCP server that if a - request is received from a client that matches the MAC - address of a host declaration, any other leases matching - that MAC address should be discarded by the server, even - if the UID is not the same. This is a violation of the - DHCP protocol, but can prevent clients whose client iden­ - tifiers change regularly from holding many leases at the - same time. By default, duplicates are aalllloowwed. TThhee - _d_e_c_l_i_n_e_s kkeeyywwoorrdd - - aallllooww ddeecclliinneess;; - ddeennyy ddeecclliinneess;; - iiggnnoorree ddeecclliinneess;; - - The DHCPDECLINE message is used by DHCP clients to indi­ - cate that the lease the server has offered is not valid. - When the server receives a DHCPDECLINE for a particular - address, it normally abandons that address, assuming that - some unauthorized system is using it. Unfortunately, a - malicious or buggy client can, using DHCPDECLINE messages, - completely exhaust the DHCP server's allocation pool. - The server will reclaim these leases, but while the client - is running through the pool, it may cause serious thrash­ - ing in the DNS, and it will also cause the DHCP server to - forget old DHCP client address allocations. - - The ddeecclliinneess flag tells the DHCP server whether or not to - honor DHCPDECLINE messages. If it is set to ddeennyy or - iiggnnoorree in a particular scope, the DHCP server will not - respond to DHCPDECLINE messages. - -AALLLLOOWW AANNDD DDEENNYY WWIITTHHIINN PPOOOOLL DDEECCLLAARRAATTIIOONNSS - The uses of the allow and deny keyword shown in the previ­ - ous section work pretty much the same way whether the - client is sending a DHCPDISCOVER or a DHCPREQUEST message - - an address will be allocated to the client (either the - old address it's requesting, or a new address) and then - that address will be tested to see if it's okay to let the - client have it. If the client requested it, and it's not - okay, the server will send a DHCPNAK message. Otherwise, - the server will simply not respond to the client. If it - is okay to give the address to the client, the server will - - - - 17 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - send a DHCPACK message. - - The primary motivation behind pool declarations is to have - address allocation pools whose allocation policies are - different. A client may be denied access to one pool, - but allowed access to another pool on the same network - segment. In order for this to work, access control has - to be done during address allocation, not after address - allocation is done. - - When a DHCPREQUEST message is processed, address alloca­ - tion simply consists of looking up the address the client - is requesting and seeing if it's still available for the - client. If it is, then the DHCP server checks both the - address pool permit lists and the relevant in-scope allow - and deny statements to see if it's okay to give the lease - to the client. In the case of a DHCPDISCOVER message, the - allocation process is done as described previously in the - ADDRESS ALLOCATION section. - - When declaring permit lists for address allocation pools, - the following syntaxes are recognized following the allow - or deny keyword: - - kknnoowwnn cclliieennttss;; - - If specified, this statement either allows or prevents - allocation from this pool to any client that has a host - declaration (i.e., is known). A client is known if it has - a host declaration in _a_n_y scope, not just the current - scope. - - uunnkknnoowwnn cclliieennttss;; - - If specified, this statement either allows or prevents - allocation from this pool to any client that has no host - declaration (i.e., is not known). - - mmeemmbbeerrss ooff ""class"";; - - If specified, this statement either allows or prevents - allocation from this pool to any client that is a member - of the named class. - - ddyynnaammiicc bboooottpp cclliieennttss;; - - If specified, this statement either allows or prevents - allocation from this pool to any bootp client. - - aauutthheennttiiccaatteedd cclliieennttss;; - - If specified, this statement either allows or prevents - allocation from this pool to any client that has been - authenticated using the DHCP authentication protocol. - - - - 18 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - This is not yet supported. - - uunnaauutthheennttiiccaatteedd cclliieennttss;; - - If specified, this statement either allows or prevents - allocation from this pool to any client that has not been - authenticated using the DHCP authentication protocol. - This is not yet supported. - - aallll cclliieennttss;; - - If specified, this statement either allows or prevents - allocation from this pool to all clients. This can be - used when you want to write a pool declaration for some - reason, but hold it in reserve, or when you want to renum­ - ber your network quickly, and thus want the server to - force all clients that have been allocated addresses from - this pool to obtain new addresses immediately when they - next renew. - -RREEFFEERREENNCCEE:: PPAARRAAMMEETTEERRSS - TThhee _l_e_a_s_e_-_f_i_l_e_-_n_a_m_e ssttaatteemmeenntt - - lleeaassee--ffiillee--nnaammee _n_a_m_e;; - - _N_a_m_e should be the name of the DHCP server's lease file. - By default, this is /var/db/dhcpd.leases. This statement - mmuusstt appear in the outer scope of the configuration file - - if it appears in some other scope, it will have no effect. - - TThhee _p_i_d_-_f_i_l_e_-_n_a_m_e ssttaatteemmeenntt - - ppiidd--ffiillee--nnaammee _n_a_m_e;; - - _N_a_m_e should be the name of the DHCP server's process ID - file. This is the file in which the DHCP server's pro­ - cess ID is stored when the server starts. By default, - this is /var/run/dhcpd.pid. Like the lease-file-name - statement, this statement must appear in the outer scope - of the configuration file. - - TThhee _d_e_f_a_u_l_t_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt - - ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e;; - - _T_i_m_e should be the length in seconds that will be assigned - to a lease if the client requesting the lease does not ask - for a specific expiration time. - - TThhee _m_a_x_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt - - mmaaxx--lleeaassee--ttiimmee _t_i_m_e;; - - _T_i_m_e should be the maximum length in seconds that will be - - - - 19 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - assigned to a lease. The only exception to this is that - Dynamic BOOTP lease lengths, which are not specified by - the client, are not limited by this maximum. - - TThhee _m_i_n_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt - - mmiinn--lleeaassee--ttiimmee _t_i_m_e;; - - _T_i_m_e should be the minimum length in seconds that will be - assigned to a lease. - - TThhee _m_i_n_-_s_e_c_s ssttaatteemmeenntt - - mmiinn--sseeccss _s_e_c_o_n_d_s;; - - _S_e_c_o_n_d_s should be the minimum number of seconds since a - client began trying to acquire a new lease before the DHCP - server will respond to its request. The number of seconds - is based on what the client reports, and the maximum value - that the client can report is 255 seconds. Generally, - setting this to one will result in the DHCP server not - responding to the client's first request, but always - responding to its second request. - - This can be used to set up a secondary DHCP server which - never offers an address to a client until the primary - server has been given a chance to do so. If the primary - server is down, the client will bind to the secondary - server, but otherwise clients should always bind to the - primary. Note that this does not, by itself, permit a - primary server and a secondary server to share a pool of - dynamically-allocatable addresses. - - TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt - - hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s;; - - In order for a BOOTP client to be recognized, its network - hardware address must be declared using a _h_a_r_d_w_a_r_e clause - in the _h_o_s_t statement. _h_a_r_d_w_a_r_e_-_t_y_p_e must be the name of - a physical hardware interface type. Currently, only the - eetthheerrnneett and ttookkeenn--rriinngg types are recognized, although - support for a ffddddii hardware type (and others) would also - be desirable. The _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s should be a set of - hexadecimal octets (numbers from 0 through ff) seperated - by colons. The _h_a_r_d_w_a_r_e statement may also be used for - DHCP clients. - - TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt - - ffiilleennaammee ""_f_i_l_e_n_a_m_e"";; - - The _f_i_l_e_n_a_m_e statement can be used to specify the name of - the initial boot file which is to be loaded by a client. - - - - 20 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - The _f_i_l_e_n_a_m_e should be a filename recognizable to whatever - file transfer protocol the client can be expected to use - to load the file. - - TThhee _s_e_r_v_e_r_-_n_a_m_e ssttaatteemmeenntt - - sseerrvveerr--nnaammee ""_n_a_m_e"";; - - The _s_e_r_v_e_r_-_n_a_m_e statement can be used to inform the client - of the name of the server from which it is booting. _N_a_m_e - should be the name that will be provided to the client. - - TThhee _n_e_x_t_-_s_e_r_v_e_r ssttaatteemmeenntt - - nneexxtt--sseerrvveerr _s_e_r_v_e_r_-_n_a_m_e;; - - The _n_e_x_t_-_s_e_r_v_e_r statement is used to specify the host - address of the server from which the initial boot file - (specified in the _f_i_l_e_n_a_m_e statement) is to be loaded. - _S_e_r_v_e_r_-_n_a_m_e should be a numeric IP address or a domain - name. If no _n_e_x_t_-_s_e_r_v_e_r parameter applies to a given - client, the DHCP server's IP address is used. - - TThhee _f_i_x_e_d_-_a_d_d_r_e_s_s ssttaatteemmeenntt - - ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [,, _a_d_d_r_e_s_s ... ];; - - The _f_i_x_e_d_-_a_d_d_r_e_s_s statement is used to assign one or more - fixed IP addresses to a client. It should only appear in - a _h_o_s_t declaration. If more than one address is supplied, - then when the client boots, it will be assigned the - address which corresponds to the network on which it is - booting. If none of the addresses in the _f_i_x_e_d_-_a_d_d_r_e_s_s - statement are on the network on which the client is boot­ - ing, that client will not match the _h_o_s_t declaration con­ - taining that _f_i_x_e_d_-_a_d_d_r_e_s_s statement. Each _a_d_d_r_e_s_s should - be either an IP address or a domain name which resolves to - one or more IP addresses. - - TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f ssttaatteemmeenntt - - ddyynnaammiicc--bboooottpp--lleeaassee--ccuuttooffff _d_a_t_e;; - - The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f statement sets the ending - time for all leases assigned dynamically to BOOTP clients. - Because BOOTP clients do not have any way of renewing - leases, and don't know that their leases could expire, by - default dhcpd assignes infinite leases to all BOOTP - clients. However, it may make sense in some situations to - set a cutoff date for all BOOTP leases - for example, the - end of a school term, or the time at night when a facility - is closed and all machines are required to be powered off. - - _D_a_t_e should be the date on which all assigned BOOTP leases - - - - 21 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - will end. The date is specified in the form: - - W YYYY/MM/DD HH:MM:SS - - W is the day of the week expressed as a number from zero - (Sunday) to six (Saturday). YYYY is the year, including - the century. MM is the month expressed as a number from 1 - to 12. DD is the day of the month, counting from 1. HH - is the hour, from zero to 23. MM is the minute and SS is - the second. The time is always in Greenwich Mean Time - (GMT), not local time. - - TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h ssttaatteemmeenntt - - ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;; - - The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h statement is used to set - the length of leases dynamically assigned to BOOTP - clients. At some sites, it may be possible to assume - that a lease is no longer in use if its holder has not - used BOOTP or DHCP to get its address within a certain - time period. The period is specified in _l_e_n_g_t_h as a num­ - ber of seconds. If a client reboots using BOOTP during - the timeout period, the lease duration is reset to _l_e_n_g_t_h, - so a BOOTP client that boots frequently enough will never - lose its lease. Needless to say, this parameter should be - adjusted with extreme caution. - - TThhee _g_e_t_-_l_e_a_s_e_-_h_o_s_t_n_a_m_e_s ssttaatteemmeenntt - - ggeett--lleeaassee--hhoossttnnaammeess _f_l_a_g;; - - The _g_e_t_-_l_e_a_s_e_-_h_o_s_t_n_a_m_e_s statement is used to tell dhcpd - whether or not to look up the domain name corresponding to - the IP address of each address in the lease pool and use - that address for the DHCP _h_o_s_t_n_a_m_e option. If _f_l_a_g is - true, then this lookup is done for all addresses in the - current scope. By default, or if _f_l_a_g is false, no - lookups are done. - - TThhee _u_s_e_-_h_o_s_t_-_d_e_c_l_-_n_a_m_e_s ssttaatteemmeenntt - - uussee--hhoosstt--ddeeccll--nnaammeess _f_l_a_g;; - - If the _u_s_e_-_h_o_s_t_-_d_e_c_l_-_n_a_m_e_s parameter is true in a given - scope, then for every host declaration within that scope, - the name provided for the host declaration will be sup­ - plied to the client as its hostname. So, for example, - - group { - use-host-decl-names on; - - host joe { - hardware ethernet 08:00:2b:4c:29:32; - - - - 22 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - fixed-address joe.fugue.com; - } - } - - is equivalent to - - host joe { - hardware ethernet 08:00:2b:4c:29:32; - fixed-address joe.fugue.com; - option host-name "joe"; - } - - An _o_p_t_i_o_n _h_o_s_t_-_n_a_m_e statement within a host declaration - will override the use of the name in the host declaration. - - TThhee _a_u_t_h_o_r_i_t_a_t_i_v_e ssttaatteemmeenntt - - aauutthhoorriittaattiivvee;; - - nnoott aauutthhoorriittaattiivvee;; - - The DHCP server will normally assume that the configura­ - tion information about a given network segment is not - known to be correct and is not authoritative. This is so - that if a naive user installs a DHCP server not fully - understanding how to configure it, it does not send spuri­ - ous DHCPNAK messages to clients that have obtained - addresses from a legitimate DHCP server on the network. - - Network administrators setting up authoritative DHCP - servers for their networks should always write aauutthhoorriittaa­­ - ttiivvee;; at the top of their configuration file to indicate - that the DHCP server _s_h_o_u_l_d send DHCPNAK messages to mis­ - configured clients. If this is not done, clients will be - unable to get a correct IP address after changing subnets - until their old lease has expired, which could take quite - a long time. - - Usually, writing aauutthhoorriittaattiivvee;; at the top level of the - file should be sufficient. However, if a DHCP server is - to be set up so that it is aware of some networks for - which it is authoritative and some networks for which it - is not, it may be more appropriate to declare authority on - a per-network-segment basis. - - Note that the most specific scope for which the concept of - authority makes any sense is the physical network segment - - either a shared-network statement or a subnet statement - that is not contained within a shared-network statement. - It is not meaningful to specify that the server is author­ - itative for some subnets within a shared network, but not - authoritative for others, nor is it meaningful to specify - that the server is authoritative for some host declara­ - tions and not others. - - - - 23 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - TThhee _a_l_w_a_y_s_-_r_e_p_l_y_-_r_f_c_1_0_4_8 ssttaatteemmeenntt - - aallwwaayyss--rreeppllyy--rrffcc11004488 _f_l_a_g;; - - Some BOOTP clients expect RFC1048-style responses, but do - not follow RFC1048 when sending their requests. You can - tell that a client is having this problem if it is not - getting the options you have configured for it and if you - see in the server log the message "(non-rfc1048)" printed - with each BOOTREQUEST that is logged. - - If you want to send rfc1048 options to such a client, you - can set the aallwwaayyss--rreeppllyy--rrffcc11004488 option in that client's - host declaration, and the DHCP server will respond with an - RFC-1048-style vendor options field. This flag can be - set in any scope, and will affect all clients covered by - that scope. - - TThhee _a_l_w_a_y_s_-_b_r_o_a_d_c_a_s_t ssttaatteemmeenntt - - aallwwaayyss--bbrrooaaddccaasstt _f_l_a_g;; - - The DHCP and BOOTP protocols both require DHCP and BOOTP - clients to set the broadcast bit in the flags field of the - BOOTP message header. Unfortunately, some DHCP and BOOTP - clients do not do this, and therefore may not receive - responses from the DHCP server. The DHCP server can be - made to always broadcast its responses to clients by set­ - ting this flag to 'on' for the relevant scope. To avoid - creating excess broadcast traffic on your network, we rec­ - ommend that you restrict the use of this option to as few - clients as possible. For example, the Microsoft DHCP - client is known not to have this problem, as are the Open­ - Transport and ISC DHCP clients. - - TThhee _o_n_e_-_l_e_a_s_e_-_p_e_r_-_c_l_i_e_n_t ssttaatteemmeenntt - - oonnee--lleeaassee--ppeerr--cclliieenntt _f_l_a_g;; - - If this flag is enabled, whenever a client sends a DHCPRE­ - QUEST for a particular lease, the server will automati­ - cally free any other leases the client holds. This pre­ - sumes that when the client sends a DHCPREQUEST, it has - forgotten any lease not mentioned in the DHCPREQUEST - - i.e., the client has only a single network interface _a_n_d - it does not remember leases it's holding on networks to - which it is not currently attached. Neither of these - assumptions are guaranteed or provable, so we urge caution - in the use of this statement. - - TThhee _u_s_e_-_l_e_a_s_e_-_a_d_d_r_-_f_o_r_-_d_e_f_a_u_l_t_-_r_o_u_t_e ssttaatteemmeenntt - - uussee--lleeaassee--aaddddrr--ffoorr--ddeeffaauulltt--rroouuttee _f_l_a_g;; - - - - - 24 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - If the _u_s_e_-_l_e_a_s_e_-_a_d_d_r_-_f_o_r_-_d_e_f_a_u_l_t_-_r_o_u_t_e parameter is true - in a given scope, then instead of sending the value speci­ - fied in the routers option (or sending no value at all), - the IP address of the lease being assigned is sent to the - client. This supposedly causes Win95 machines to ARP for - all IP addresses, which can be helpful if your router is - configured for proxy ARP. - - TThhee _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r ssttaatteemmeenntt - - sseerrvveerr--iiddeennttiiffiieerr _h_o_s_t_n_a_m_e;; - - The server-identifier statement can be used to define the - value that is sent in the DHCP Server Identifier option - for a given scope. The value specified mmuusstt be an IP - address for the DHCP server, and must be reachable by all - clients served by a particular scope. - - The use of the server-identifier statement is not recom­ - mended - the only reason to use it is to force a value - other than the default value to be sent on occasions where - the default value would be incorrect. The default value - is the first IP address associated with the physical net­ - work interface on which the request arrived. - - The usual case where the _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r statement needs - to be sent is when a physical interface has more than one - IP address, and the one being sent by default isn't appro­ - priate for some or all clients served by that interface. - Another common case is when an alias is defined for the - purpose of having a consistent IP address for the DHCP - server, and it is desired that the clients use this IP - address when contacting the server. - - Supplying a value for the dhcp-server-identifier option is - equivalent to using the server-identifier statement. - - TThhee _d_d_n_s_-_u_p_d_a_t_e_s ssttaatteemmeenntt - - ddddnnss--uuppddaatteess _f_l_a_g;; - - The _d_d_n_s_-_u_p_d_a_t_e_s parameter controls whether or not the - server will attempt to do a ddns update when a lease is - confirmed. Set this to _o_f_f if the server should not - attempt to do updates within a certain scope. The _d_d_n_s_- - _u_p_d_a_t_e_s parameter is on by default. - -RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS - DHCP option statements are documented in the ddhhccpp-- - ooppttiioonnss((55)) manual page. - -SSEEEE AALLSSOO - dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131. - - - - - 25 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - -AAUUTTHHOORR - ddhhccppdd((88)) was written by Ted Lemon under a - contract with Vixie Labs. Funding for this project was - provided by the Internet Software Consortium. Information - about the Internet Software Consortium can be found at - hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 26 - - diff --git a/server/dhcpd.leases.cat5 b/server/dhcpd.leases.cat5 deleted file mode 100644 index f509e6221..000000000 --- a/server/dhcpd.leases.cat5 +++ /dev/null @@ -1,198 +0,0 @@ - - - -dhcpd.leases(5) dhcpd.leases(5) - - -NNAAMMEE - dhcpd.leases - DHCP client lease database - -DDEESSCCRRIIPPTTIIOONN - The Internet Software Consortium DHCP Server keeps a per­ - sistent database of leases that it has assigned. This - database is a free-form ASCII file containing a series of - lease declarations. Every time a lease is acquired, - renewed or released, its new value is recorded at the end - of the lease file. So if more than one declaration - appears for a given lease, the last one in the file is the - current one. - - When dhcpd is first installed, there is no lease database. - However, dhcpd requires that a lease database be present - before it will start. To make the initial lease database, - just create an empty file called /var/db/dhcpd.leases. - - In order to prevent the lease database from growing with­ - out bound, the file is rewritten from time to time. - First, a temporary lease database is created and all known - leases are dumped to it. Then, the old lease database is - renamed /var/db/dhcpd.leases~. Finally, the newly writ­ - ten lease database is moved into place. - - There is a window of vulnerability where if the dhcpd pro­ - cess is killed or the system crashes after the old lease - database has been renamed but before the new one has been - moved into place, there will be no /var/db/dhcpd.leases. - In this case, dhcpd will refuse to start, and will require - manual intervention. DDOO NNOOTT simply create a new lease - file when this happens - if you do, you will lose all your - old bindings, and chaos will ensue. Instead, rename - /var/db/dhcpd.leases~ to /var/db/dhcpd.leases, restoring - the old, valid lease file, and then start dhcpd. This - guarantees that a valid lease file will be restored. - -FFOORRMMAATT - Lease descriptions are stored in a format that is parsed - by the same recursive descent parser used to read the - ddhhccppdd..ccoonnff((55)) and ddhhcclliieenntt..ccoonnff((55)) files. Currently, the - only declaration that is used in the dhcpd.leases file is - the lleeaassee declaration. - - lleeaassee _i_p_-_a_d_d_r_e_s_s {{ _s_t_a_t_e_m_e_n_t_s_._._. }} - - Each lease declaration include the single IP address that - has been leased to the client. The statements within the - braces define the duration of the lease and to whom it is - assigned. - - The start and end time of a lease are recorded using the - ``starts'' and ``ends'' statements: - - - - - 1 - - - - - -dhcpd.leases(5) dhcpd.leases(5) - - - ssttaarrttss _d_a_t_e;; - eennddss _d_a_t_e;; - - Dates are specified as follows: - - _w_e_e_k_d_a_y _y_e_a_r//_m_o_n_t_h//_d_a_y _h_o_u_r::_m_i_n_u_t_e::_s_e_c_o_n_d - - The weekday is present to make it easy for a human to tell - when a lease expires - it's specified as a number from - zero to six, with zero being Sunday. The day of week is - ignored on input. The year is specified with the century, - so it should generally be four digits except for really - long leases. The month is specified as a number starting - with 1 for January. The day of the month is likewise - specified starting with 1. The hour is a number between 0 - and 23, the minute a number between 0 and 59, and the sec­ - ond also a number between 0 and 59. - - Lease times are specified in Greenwich Mean Time (GMT), - not in the local time zone. Since Greenwich is actually - on Daylight Savings Time part of the year, there is proba­ - bly nowhere in the world where the times recorded on a - lease are always the same as wall clock times. On a unix - machine, one can often figure out the current time in GMT - by typing ddaattee --uu. - - The MAC address of the network interface that was used to - acquire the lease is recorded with the hhaarrddwwaarree statement: - - hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _m_a_c_-_a_d_d_r_e_s_s;; - - The MAC address is specified as a series of hexadecimal - octets, seperated by colons. - - If the client used a client identifier to acquire its - address, the client identifier is recorded using the uuiidd - statement: - - uuiidd _c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r;; - - The client identifier is recorded as a series of hexadeci­ - mal octets, regardless of whether the client specifies an - ASCII string or uses the newer hardware type/MAC address - format. - - If the client sends a hostname using the _C_l_i_e_n_t _H_o_s_t_n_a_m_e - option, as specified in some versions of the DHCP-DNS - Interaction draft, that hostname is recorded using the - cclliieenntt--hhoossttnnaammee statement. - - cclliieenntt--hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";; - - If the client sends its hostname using the _H_o_s_t_n_a_m_e - option, as Windows 95 does, it is recorded using the - - - - 2 - - - - - -dhcpd.leases(5) dhcpd.leases(5) - - - hhoossttnnaammee statement. - - hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";; - - The DHCP server may determine that a lease has been mis­ - used in some way, either because a client that has been - assigned a lease NAKs it, or because the server's own - attempt to see if an address is in use prior to reusing it - reveals that the address is in fact already in use. In - that case, the aabbaannddoonneedd statement will be used to indi­ - cate that the lease should not be reassigned. - - aabbaannddoonneedd;; - - Abandoned leases are reclaimed automatically. When a - client asks for a new address, and the server finds that - there are no new addresses, it checks to see if there are - any abandoned leases, and allocates the least recently - abandoned lease. The standard mechanisms for checking - for lease address conflicts are still followed, so if the - abandoned lease's IP address is still in use, it will be - reabandoned. - - If a client rreeqquueessttss an abandoned address, the server - assumes that the reason the address was abandoned was that - the lease file was corrupted, and that the client is the - machine that responded when the lease was probed, causing - it to be abandoned. In that case, the address is immedi­ - ately assigned to the client. - -FFIILLEESS - //vvaarr//ddbb//ddhhccppdd..lleeaasseess - -SSEEEE AALLSSOO - dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132, - RFC2131. - -AAUUTTHHOORR - ddhhccppdd((88)) was written by Ted Lemon under a - contract with Vixie Labs. Funding for this project was - provided by the Internet Software Corporation. Informa­ - tion about the Internet Software Consortium can be found - at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - 3 - -