bringing HEAD up to par with V3-0-3-BETA-1.
+++ /dev/null
- 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.
-
-
+++ /dev/null
-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.
-
+++ /dev/null
-/*
- * 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.
- */
+++ /dev/null
-/* 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);
-}
-
+++ /dev/null
-.\" 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 <mellon@isc.org> 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.
+++ /dev/null
-
-
-
-dhcp-contrib(5) dhcp-contrib(5)
-
-
-N\bNA\bAM\bME\bE
- Contributing to the Internet Software Consortium DHCP Dis
- tribution
-
-E\bEX\bXH\bHO\bOR\bRT\bTA\bAT\bTI\bIO\bON\bN
- 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.
-
-F\bFR\bRE\bEQ\bQU\bUE\bEN\bNT\bTL\bLY\bY A\bAS\bSK\bKE\bED\bD Q\bQU\bUE\bES\bST\bTI\bIO\bON\bNS\bS
- 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.
-
-S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5),
- dhcpd(8), dhclient(8), RFC2132, RFC2131.
-
-A\bAU\bUT\bTH\bHO\bOR\bR
- The Internet Software Consortium DHCP Distribution was
-
-
-
- 4
-
-
-
-
-
-dhcp-contrib(5) dhcp-contrib(5)
-
-
- written by Ted Lemon <mellon@isc.org> 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
- h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 5
-
-
+++ /dev/null
-
-
-
-dhcpd-options(5) dhcpd-options(5)
-
-
-N\bNA\bAM\bME\bE
- dhcp-conditionals - ISC DHCP conditional evaluation
-
-D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
- 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.
-
-R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: C\bCO\bON\bND\bDI\bIT\bTI\bIO\bON\bNA\bAL\bL B\bBE\bEH\bHA\bAV\bVI\bIO\bOU\bUR\bR
- 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 i\bif\bf statement and the e\bel\bls\bsi\bif\bf 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 i\bif\bf
- statement are executed, and all subsequent e\bel\bls\bsi\bif\bf and e\bel\bls\bse\be
- clauses are skipped. Otherwise, each subsequent e\bel\bls\bsi\bif\bf
- 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 e\bel\bls\bsi\bif\bf and e\bel\bls\bse\be clauses
- are skipped. If all the i\bif\bf and e\bel\bls\bsi\bif\bf clauses are checked
- but none of their expressions evaluate true, then if there
- is an e\bel\bls\bse\be clause, the statements enclosed in braces fol
- lowing the e\bel\bls\bse\be are evaluated. Boolean expressions that
- evaluate to null are treated as false in conditionals.
-
-B\bBO\bOO\bOL\bLE\bEA\bAN\bN E\bEX\bXP\bPR\bRE\bES\bSS\bSI\bIO\bON\bNS\bS
- The following is the current list of boolean expressions
- that are supported by the DHCP distribution.
-
- c\bch\bhe\bec\bck\bk _\bc_\bl_\ba_\bs_\bs_\b-_\bn_\ba_\bm_\be
-
- The check operator returns a true value if the packet
- being considered comes from a client that falls into
- the specified class. _\bC_\bl_\ba_\bs_\bs_\b-_\bn_\ba_\bm_\be must be a string that
- corresponds to the name of a defined class. Classes
- are only supported in the DHCP server.
-
- _\bd_\ba_\bt_\ba_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn_\b-_\b1 =\b= _\bd_\ba_\bt_\ba_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn_\b-_\b2
-
- The =\b= 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.
-
- _\bb_\bo_\bo_\bl_\be_\ba_\bn_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn_\b-_\b1 a\ban\bnd\bd _\bb_\bo_\bo_\bl_\be_\ba_\bn_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn_\b-_\b2
-
- The a\ban\bnd\bd 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.
-
- _\bb_\bo_\bo_\bl_\be_\ba_\bn_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn_\b-_\b1 o\bor\br _\bb_\bo_\bo_\bl_\be_\ba_\bn_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn_\b-_\b2
-
- The o\bor\br 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.
-
- n\bno\bot\bt _\bb_\bo_\bo_\bl_\be_\ba_\bn_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn
-
- The n\bno\bot\bt operator evaluates to true if _\bb_\bo_\bo_\bl_\be_\ba_\bn_\b-_\be_\bx_\bp_\br_\be_\bs_\b
- _\bs_\bi_\bo_\bn evaluates to false, and returns false if _\bb_\bo_\bo_\bl_\be_\ba_\bn_\b-
-
-
-
- 2
-
-
-
-
-
-dhcpd-options(5) dhcpd-options(5)
-
-
- _\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn evaluates to true. If _\bb_\bo_\bo_\bl_\be_\ba_\bn_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn
- evaluates to null, the result is also null.
-
- e\bex\bxi\bis\bst\bts\bs _\bo_\bp_\bt_\bi_\bo_\bn_\b-_\bn_\ba_\bm_\be
-
- The e\bex\bxi\bis\bst\bts\bs expression returns true if the specified
- option exists in the incoming DHCP packet being pro
- cessed.
- k\bkn\bno\bow\bwn\bn
-
- The k\bkn\bno\bow\bwn\bn expression returns true if the client whose
- request is currently being processed is known - that
- is, if there's a host declaration for it.
- s\bst\bta\bat\bti\bic\bc
-
- The s\bst\bta\bat\bti\bic\bc expression returns true if the lease
- assigned to the client whose request is currently being
- processed is derived from a static address assignment.
-
-D\bDA\bAT\bTA\bA E\bEX\bXP\bPR\bRE\bES\bSS\bSI\bIO\bON\bNS\bS
- Several of the boolean expressions above depend on the
- results of evaluating data expressions. A list of these
- expressions is provided here.
-
- s\bsu\bub\bbs\bst\btr\bri\bin\bng\bg (\b(_\bd_\ba_\bt_\ba_\b-_\be_\bx_\bp_\br,\b, _\bo_\bf_\bf_\bs_\be_\bt,\b, _\bl_\be_\bn_\bg_\bt_\bh)\b)
-
- The s\bsu\bub\bbs\bst\btr\bri\bin\bng\bg operator evaluates the data expression
- and returns the substring of the result of that evalua
- tion that starts _\bo_\bf_\bf_\bs_\be_\bt bytes from the beginning, con
- tinuing for _\bl_\be_\bn_\bg_\bt_\bh bytes. _\bO_\bf_\bf_\bs_\be_\bt and _\bl_\be_\bn_\bg_\bt_\bh are both
- numeric expressions. If _\bd_\ba_\bt_\ba_\b-_\be_\bx_\bp_\br, _\bo_\bf_\bf_\bs_\be_\bt or _\bl_\be_\bn_\bg_\bt_\bh
- evaluate to null, then the result is also null. If
- _\bo_\bf_\bf_\bs_\be_\bt is greater than or equal to the length of the
- evaluated data, then a zero-length data string is
- returned. If _\bl_\be_\bn_\bg_\bt_\bh _\bi_\bs _\bg_\br_\be_\ba_\bt_\be_\br _\bt_\bh_\be_\bn _\bt_\bh_\be _\br_\be_\bm_\ba_\bi_\bn_\bi_\bn_\bg
- _\bl_\be_\bn_\bg_\bt_\bh _\bo_\bf _\bt_\bh_\be _\be_\bv_\ba_\bl_\bu_\ba_\bt_\be_\bd _\bd_\ba_\bt_\ba _\ba_\bf_\bt_\be_\br _\bo_\bf_\bf_\bs_\be_\bt, then a data
- string containing all data from _\bo_\bf_\bf_\bs_\be_\bt to the end of
- the evaluated data is returned.
-
- s\bsu\buf\bff\bfi\bix\bx (\b(_\bd_\ba_\bt_\ba_\b-_\be_\bx_\bp_\br,\b, _\bl_\be_\bn_\bg_\bt_\bh)\b)
-
- The s\bsu\buf\bff\bfi\bix\bx operator evaluates _\bd_\ba_\bt_\ba_\b-_\be_\bx_\bp_\br and returns the
- last _\bl_\be_\bn_\bg_\bt_\bh bytes of the result of that evaluation.
- _\bL_\be_\bn_\bg_\bt_\bh is a numeric expression. If _\bd_\ba_\bt_\ba_\b-_\be_\bx_\bp_\br or _\bl_\be_\bn_\bg_\bt_\bh
- evaluate to null, then the result is also null. If
- _\bs_\bu_\bf_\bf_\bi_\bx evaluates to a number greater than the length of
- the evaluated data, then the evaluated data is
- returned.
-
- o\bop\bpt\bti\bio\bon\bn _\bo_\bp_\bt_\bi_\bo_\bn_\b-_\bn_\ba_\bm_\be
-
- The o\bop\bpt\bti\bio\bon\bn 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)
-
-
- h\bha\bar\brd\bdw\bwa\bar\bre\be
-
- The h\bha\bar\brd\bdw\bwa\bar\bre\be 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 _\bh_\bl_\be_\bn 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).
-
- p\bpa\bac\bck\bke\bet\bt (\b(_\bo_\bf_\bf_\bs_\be_\bt,\b, _\bl_\be_\bn_\bg_\bt_\bh)\b)
-
- The p\bpa\bac\bck\bke\bet\bt operator returns the specified portion of
- the packet being considered, or null in contexts where
- no packet is being considered. _\bO_\bf_\bf_\bs_\be_\bt and _\bl_\be_\bn_\bg_\bt_\bh are
- applied to the contents packet as in the s\bsu\bub\bbs\bst\btr\bri\bin\bng\bg
- operator.
-
- _\bs_\bt_\br_\bi_\bn_\bg
-
- A string, enclosed in quotes, may be specified as a
- data expression, and returns the text between the
- quotes, encoded in ASCII.
-
- _\bc_\bo_\bl_\bo_\bn_\b-_\bs_\be_\bp_\be_\br_\ba_\bt_\be_\bd _\bh_\be_\bx_\ba_\bd_\be_\bc_\bi_\bm_\ba_\bl _\bl_\bi_\bs_\bt
-
- A list of hexadecimal octet values, seperated by
- colons, may be specified as a data expression.
-
- c\bco\bon\bnc\bca\bat\bt (\b(_\bd_\ba_\bt_\ba_\b-_\be_\bx_\bp_\br_\b1,\b, .\b..\b..\b.,\b, _\bd_\ba_\bt_\ba_\b-_\be_\bx_\bp_\br_\bN)\b)
- 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.
-
- r\bre\bev\bve\ber\brs\bse\be (\b(_\bn_\bu_\bm_\be_\br_\bi_\bc_\b-_\be_\bx_\bp_\br_\b1,\b, _\bd_\ba_\bt_\ba_\b-_\be_\bx_\bp_\br_\b2)\b)
- 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.
-
- l\ble\bea\bas\bse\bed\bd-\b-a\bad\bdd\bdr\bre\bes\bss\bs
- 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)
-
-
- b\bbi\bin\bna\bar\bry\by-\b-t\bto\bo-\b-a\bas\bsc\bci\bii\bi (\b(_\bn_\bu_\bm_\be_\br_\bi_\bc_\b-_\be_\bx_\bp_\br_\b1,\b, _\bn_\bu_\bm_\be_\br_\bi_\bc_\b-_\be_\bx_\bp_\br_\b2,\b, _\bd_\ba_\bt_\ba_\b-_\be_\bx_\bp_\br_\b1,\b,
- _\bd_\ba_\bt_\ba_\b-_\be_\bx_\bp_\br_\b2)\b)
- 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.");
-
-
- e\ben\bnc\bco\bod\bde\be-\b-i\bin\bnt\bt (\b(_\bn_\bu_\bm_\be_\br_\bi_\bc_\b-_\be_\bx_\bp_\br,\b, _\bw_\bi_\bd_\bt_\bh)\b)
- 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.
-
- p\bpi\bic\bck\bk-\b-f\bfi\bir\brs\bst\bt-\b-v\bva\bal\blu\bue\be (\b(_\bd_\ba_\bt_\ba_\b-_\be_\bx_\bp_\br_\b1 [ ... _\be_\bx_\bp_\brn ] )\b)
- 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.
-
- h\bho\bos\bst\bt-\b-d\bde\bec\bcl\bl-\b-n\bna\bam\bme\be
- 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.
-
-N\bNU\bUM\bME\bER\bRI\bIC\bC E\bEX\bXP\bPR\bRE\bES\bSS\bSI\bIO\bON\bNS\bS
- 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.
-
- e\bex\bxt\btr\bra\bac\bct\bt-\b-i\bin\bnt\bt (\b(_\bd_\ba_\bt_\ba_\b-_\be_\bx_\bp_\br,\b, _\bw_\bi_\bd_\bt_\bh)\b)
-
-
-
-
- 5
-
-
-
-
-
-dhcpd-options(5) dhcpd-options(5)
-
-
- The e\bex\bxt\btr\bra\bac\bct\bt-\b-i\bin\bnt\bt 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.
-
- l\ble\bea\bas\bse\be-\b-t\bti\bim\bme\be
-
- The duration of the current lease - that is, the dif
- ference between the current time and the time that the
- lease expires.
-
- _\bn_\bu_\bm_\bb_\be_\br
-
- Any number between zero and the maximum representable
- size may be specified as a numeric expression.
-
-R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: D\bDY\bYN\bNA\bAM\bMI\bIC\bC D\bDN\bNS\bS U\bUP\bPD\bDA\bAT\bTE\bES\bS
- 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.
-
-S\bSE\bEC\bCU\bUR\bRI\bIT\bTY\bY
- 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 d\bdn\bns\bs-\b-
- u\bup\bpd\bda\bat\bte\be expression. The d\bdn\bns\bs-\b-u\bup\bpd\bda\bat\bte\be 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 d\bdn\bns\bs-\b-u\bup\bpd\bda\bat\bte\beR\bR.\b.
-
- 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 d\bdn\bns\bs-\b-u\bup\bpd\bda\bat\bte\be 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.
-
-S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-
- eval(5), dhcpd(8), dhclient(8), RFC2132, RFC2131.
-
-A\bAU\bUT\bTH\bHO\bOR\bR
- The Internet Software Consortium DHCP Distribution was
- written by Ted Lemon <mellon@isc.org> 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
- h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 7
-
-
+++ /dev/null
-
-
-
-dhcpd-options(5) dhcpd-options(5)
-
-
-N\bNA\bAM\bME\bE
- dhcp-options - Dynamic Host Configuration Protocol options
-
-D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
- The Dynamic Host Configuration protocol allows the client
- to receive o\bop\bpt\bti\bio\bon\bns\bs from the DHCP server describing the
- network configuration and various services that are avail
- able on the network. When configuring d\bdh\bhc\bcp\bpd\bd(\b(8\b8)\b) or
- d\bdh\bhc\bcl\bli\bie\ben\bnt\bt(\b(8\b8)\b) ,\b, 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.
-
-R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: O\bOP\bPT\bTI\bIO\bON\bN S\bST\bTA\bAT\bTE\bEM\bME\bEN\bNT\bTS\bS
- DHCP _\bo_\bp_\bt_\bi_\bo_\bn statements always start with the _\bo_\bp_\bt_\bi_\bo_\bn 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 i\bip\bp-\b-a\bad\bdd\bdr\bre\bes\bss\bs 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 i\bin\bnt\bt3\b32\b2 data type specifies a signed 32-bit integer.
- The u\bui\bin\bnt\bt3\b32\b2 data type specifies an unsigned 32-bit integer.
- The i\bin\bnt\bt1\b16\b6 and u\bui\bin\bnt\bt1\b16\b6 data types specify signed and
- unsigned 16-bit integers. The i\bin\bnt\bt8\b8 and u\bui\bin\bnt\bt8\b8 data types
- specify signed and unsigned 8-bit integers. Unsigned
- 8-bit integers are also sometimes referred to as octets.
-
- The t\bte\bex\bxt\bt 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 f\bfl\bla\bag\bg 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 s\bst\btr\bri\bin\bng\bg 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-_\bn_\bn_\bn, where _\bn_\bn_\bn 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:
-
- o\bop\bpt\bti\bio\bon\bn a\bal\bll\bl-\b-s\bsu\bub\bbn\bne\bet\bts\bs-\b-l\blo\boc\bca\bal\bl _\bf_\bl_\ba_\bg;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn a\bar\brp\bp-\b-c\bca\bac\bch\bhe\be-\b-t\bti\bim\bme\beo\bou\but\bt _\bu_\bi_\bn_\bt_\b3_\b2;\b;
-
- This option specifies the timeout in seconds for ARP
- cache entries.
-
- o\bop\bpt\bti\bio\bon\bn b\bbo\boo\bot\btf\bfi\bil\ble\be-\b-n\bna\bam\bme\be _\bt_\be_\bx_\bt;\b;
-
- This option is used to identify a bootstrap file. If
- supported by the client, it should have the same effect
- as the f\bfi\bil\ble\ben\bna\bam\bme\be declaration. BOOTP clients are
- unlikely to support this option. Some DHCP clients
- will support it, and others actually require it.
-
- o\bop\bpt\bti\bio\bon\bn b\bbo\boo\bot\bt-\b-s\bsi\biz\bze\be _\bu_\bi_\bn_\bt_\b1_\b6;\b;
-
- This option specifies the length in 512-octet blocks of
- the default boot image for the client.
-
- o\bop\bpt\bti\bio\bon\bn b\bbr\bro\boa\bad\bdc\bca\bas\bst\bt-\b-a\bad\bdd\bdr\bre\bes\bss\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
-
- 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)
-
-
- o\bop\bpt\bti\bio\bon\bn c\bco\boo\bok\bki\bie\be-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- The cookie server option specifies a list of RFC 865
- cookie servers available to the client. Servers should
- be listed in order of preference.
-
- o\bop\bpt\bti\bio\bon\bn d\bde\bef\bfa\bau\bul\blt\bt-\b-i\bip\bp-\b-t\btt\btl\bl _\bu_\bi_\bn_\bt_\b8_\b;
-
- This option specifies the default time-to-live that the
- client should use on outgoing datagrams.
-
- o\bop\bpt\bti\bio\bon\bn d\bde\bef\bfa\bau\bul\blt\bt-\b-t\btc\bcp\bp-\b-t\btt\btl\bl _\bu_\bi_\bn_\bt_\b8;\b;
-
- This option specifies the default TTL that the client
- should use when sending TCP segments. The minimum
- value is 1.
-
- o\bop\bpt\bti\bio\bon\bn d\bdh\bhc\bcp\bp-\b-c\bcl\bli\bie\ben\bnt\bt-\b-i\bid\bde\ben\bnt\bti\bif\bfi\bie\ber\br _\bs_\bt_\br_\bi_\bn_\bg;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn d\bdh\bhc\bcp\bp-\b-m\bma\bax\bx-\b-m\bme\bes\bss\bsa\bag\bge\be-\b-s\bsi\biz\bze\be _\bu_\bi_\bn_\bt_\b1_\b6;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn d\bdh\bhc\bcp\bp-\b-p\bpa\bar\bra\bam\bme\bet\bte\ber\br-\b-r\bre\beq\bqu\bue\bes\bst\bt-\b-l\bli\bis\bst\bt _\bu_\bi_\bn_\bt_\b1_\b6;\b;
-
- 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
- _\br_\be_\bq_\bu_\be_\bs_\bt 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.
-
- o\bop\bpt\bti\bio\bon\bn d\bdo\bom\bma\bai\bin\bn-\b-n\bna\bam\bme\be _\bt_\be_\bx_\bt;\b;
-
- 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)
-
-
- o\bop\bpt\bti\bio\bon\bn d\bdo\bom\bma\bai\bin\bn-\b-n\bna\bam\bme\be-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn e\bex\bxt\bte\ben\bns\bsi\bio\bon\bns\bs-\b-p\bpa\bat\bth\bh-\b-n\bna\bam\bme\be _\bt_\be_\bx_\bt;\b;
-
- This option specifies the name of a file containing
- additional options to be interpreted according to the
- DHCP option format as specified in RFC2132.
-
- o\bop\bpt\bti\bio\bon\bn f\bfi\bin\bng\bge\ber\br-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- The Finger server option specifies a list of Finger
- available to the client. Servers should be listed in
- order of preference.
-
- o\bop\bpt\bti\bio\bon\bn f\bfo\bon\bnt\bt-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- This option specifies a list of X Window System Font
- servers available to the client. Servers should be
- listed in order of preference.
-
- o\bop\bpt\bti\bio\bon\bn h\bho\bos\bst\bt-\b-n\bna\bam\bme\be _\bs_\bt_\br_\bi_\bn_\bg;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn i\bie\bee\bee\be8\b80\b02\b2-\b-3\b3-\b-e\ben\bnc\bca\bap\bps\bsu\bul\bla\bat\bti\bio\bon\bn _\bf_\bl_\ba_\bg;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn i\bie\ben\bn1\b11\b16\b6-\b-n\bna\bam\bme\be-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn i\bim\bmp\bpr\bre\bes\bss\bs-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- 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)
-
-
- o\bop\bpt\bti\bio\bon\bn i\bin\bnt\bte\ber\brf\bfa\bac\bce\be-\b-m\bmt\btu\bu _\bu_\bi_\bn_\bt_\b1_\b6;\b;
-
- This option specifies the MTU to use on this interface.
- The minimum legal value for the MTU is 68.
-
- o\bop\bpt\bti\bio\bon\bn i\bip\bp-\b-f\bfo\bor\brw\bwa\bar\brd\bdi\bin\bng\bg _\bf_\bl_\ba_\bg;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn i\bir\brc\bc-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- The IRC server option specifies a list of IRC available
- to the client. Servers should be listed in order of
- preference.
-
- o\bop\bpt\bti\bio\bon\bn l\blo\bog\bg-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn l\blp\bpr\br-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn m\bma\bas\bsk\bk-\b-s\bsu\bup\bpp\bpl\bli\bie\ber\br _\bf_\bl_\ba_\bg;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn m\bma\bax\bx-\b-d\bdg\bgr\bra\bam\bm-\b-r\bre\bea\bas\bss\bse\bem\bmb\bbl\bly\by _\bu_\bi_\bn_\bt_\b1_\b6;\b;
-
- This option specifies the maximum size datagram that
- the client should be prepared to reassemble. The mini
- mum value legal value is 576.
-
- o\bop\bpt\bti\bio\bon\bn m\bme\ber\bri\bit\bt-\b-d\bdu\bum\bmp\bp _\bt_\be_\bx_\bt;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn m\bmo\bob\bbi\bil\ble\be-\b-i\bip\bp-\b-h\bho\bom\bme\be-\b-a\bag\bge\ben\bnt\bt _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn n\bnd\bds\bs-\b-c\bco\bon\bnt\bte\bex\bxt\bt _\bs_\bt_\br_\bi_\bn_\bg;\b;
-
- The nds-context option specifies the name of the ini
- tial Netware Directory Service for an NDS client.
-
- o\bop\bpt\bti\bio\bon\bn n\bnd\bds\bs-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- The nds-servers option specifies a list of IP addresses
- of NDS servers.
-
- o\bop\bpt\bti\bio\bon\bn n\bnd\bds\bs-\b-t\btr\bre\bee\be-\b-n\bna\bam\bme\be _\bs_\bt_\br_\bi_\bn_\bg;\b;
-
- The nds-context option specifies NDS tree name that the
- NDS client should use.
-
- o\bop\bpt\bti\bio\bon\bn n\bne\bet\btb\bbi\bio\bos\bs-\b-d\bdd\bd-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- The NetBIOS datagram distribution server (NBDD) option
- specifies a list of RFC 1001/1002 NBDD servers listed
- in order of preference.
-
- o\bop\bpt\bti\bio\bon\bn n\bne\bet\btb\bbi\bio\bos\bs-\b-n\bna\bam\bme\be-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs...];\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn n\bne\bet\btb\bbi\bio\bos\bs-\b-n\bno\bod\bde\be-\b-t\bty\byp\bpe\be _\bu_\bi_\bn_\bt_\b8;\b;
-
- 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:
-
-
- _\b1 B-node: Broadcast - no WINS
-
- _\b2 P-node: Peer - WINS only.
-
- _\b4 M-node: Mixed - broadcast, then WINS
-
- _\b8 H-node: Hybrid - WINS, then broadcast
-
- o\bop\bpt\bti\bio\bon\bn n\bne\bet\btb\bbi\bio\bos\bs-\b-s\bsc\bco\bop\bpe\be _\bs_\bt_\br_\bi_\bn_\bg;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn n\bnw\bwi\bip\bp-\b-d\bdo\bom\bma\bai\bin\bn _\bs_\bt_\br_\bi_\bn_\bg;\b;
-
- The name of the NetWare/IP domain that a NetWare/IP
- client should use.
-
- o\bop\bpt\bti\bio\bon\bn n\bnw\bwi\bip\bp-\b-s\bsu\bub\bbo\bop\bpt\bti\bio\bon\bns\bs _\bs_\bt_\br_\bi_\bn_\bg;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn n\bni\bis\bs-\b-d\bdo\bom\bma\bai\bin\bn _\bt_\be_\bx_\bt;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn n\bni\bis\bs-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- This option specifies a list of IP addresses indicating
- NIS servers available to the client. Servers should be
- listed in order of preference.
-
- o\bop\bpt\bti\bio\bon\bn n\bni\bis\bsp\bpl\blu\bus\bs-\b-d\bdo\bom\bma\bai\bin\bn _\bt_\be_\bx_\bt;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn n\bni\bis\bsp\bpl\blu\bus\bs-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- This option specifies a list of IP addresses indicating
- NIS+ servers available to the client. Servers should
- be listed in order of preference.
-
- o\bop\bpt\bti\bio\bon\bn n\bnn\bnt\btp\bp-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- The NNTP server option specifies a list of NNTP avail
- able to the client. Servers should be listed in order
- of preference.
-
- o\bop\bpt\bti\bio\bon\bn n\bno\bon\bn-\b-l\blo\boc\bca\bal\bl-\b-s\bso\bou\bur\brc\bce\be-\b-r\bro\bou\but\bti\bin\bng\bg _\bf_\bl_\ba_\bg;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn n\bnt\btp\bp-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn p\bpa\bat\bth\bh-\b-m\bmt\btu\bu-\b-a\bag\bgi\bin\bng\bg-\b-t\bti\bim\bme\beo\bou\but\bt _\bu_\bi_\bn_\bt_\b3_\b2;\b;
-
- This option specifies the timeout (in seconds) to use
- when aging Path MTU values discovered by the mechanism
- defined in RFC 1191.
-
- o\bop\bpt\bti\bio\bon\bn p\bpa\bat\bth\bh-\b-m\bmt\btu\bu-\b-p\bpl\bla\bat\bte\bea\bau\bu-\b-t\bta\bab\bbl\ble\be _\bu_\bi_\bn_\bt_\b1_\b6 [,\b, _\bu_\bi_\bn_\bt_\b1_\b6... ];\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn p\bpe\ber\brf\bfo\bor\brm\bm-\b-m\bma\bas\bsk\bk-\b-d\bdi\bis\bsc\bco\bov\bve\ber\bry\by _\bf_\bl_\ba_\bg;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn p\bpo\bol\bli\bic\bcy\by-\b-f\bfi\bil\blt\bte\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
- [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs...];\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn p\bpo\bop\bp-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- The POP3 server option specifies a list of POP3 avail
- able to the client. Servers should be listed in order
- of preference.
-
- o\bop\bpt\bti\bio\bon\bn r\bre\bes\bso\bou\bur\brc\bce\be-\b-l\blo\boc\bca\bat\bti\bio\bon\bn-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
- [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs...];\b;
-
-
-
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn r\bro\boo\bot\bt-\b-p\bpa\bat\bth\bh _\bt_\be_\bx_\bt;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn r\bro\bou\but\bte\ber\br-\b-d\bdi\bis\bsc\bco\bov\bve\ber\bry\by _\bf_\bl_\ba_\bg;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn r\bro\bou\but\bte\ber\br-\b-s\bso\bol\bli\bic\bci\bit\bta\bat\bti\bio\bon\bn-\b-a\bad\bdd\bdr\bre\bes\bss\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
-
- This option specifies the address to which the client
- should transmit router solicitation requests.
-
- o\bop\bpt\bti\bio\bon\bn r\bro\bou\but\bte\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- The routers option specifies a list of IP addresses for
- routers on the client's subnet. Routers should be
- listed in order of preference.
-
- o\bop\bpt\bti\bio\bon\bn s\bsm\bmt\btp\bp-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- The SMTP server option specifies a list of SMTP servers
- available to the client. Servers should be listed in
- order of preference.
-
- o\bop\bpt\bti\bio\bon\bn s\bst\bta\bat\bti\bic\bc-\b-r\bro\bou\but\bte\bes\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
- [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs...];\b;
-
- 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 r\bro\bou\but\bte\ber\brs\bs 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.
-
- o\bop\bpt\bti\bio\bon\bn s\bst\btr\bre\bee\bet\btt\bta\bal\blk\bk-\b-d\bdi\bir\bre\bec\bct\bto\bor\bry\by-\b-a\bas\bss\bsi\bis\bst\bta\ban\bnc\bce\be-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
- [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs...];\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn s\bst\btr\bre\bee\bet\btt\bta\bal\blk\bk-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- The StreetTalk server option specifies a list of
- StreetTalk servers available to the client. Servers
- should be listed in order of preference.
-
- o\bop\bpt\bti\bio\bon\bn s\bsu\bub\bbn\bne\bet\bt-\b-m\bma\bas\bsk\bk _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
-
- 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, _\ba_\bn_\by subnet-mask option declaration that is in
- scope for the address being assigned will override the
- subnet mask specified in the subnet declaration.
-
- o\bop\bpt\bti\bio\bon\bn s\bsw\bwa\bap\bp-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
-
- This specifies the IP address of the client's swap
- server.
-
- o\bop\bpt\bti\bio\bon\bn t\btc\bcp\bp-\b-k\bke\bee\bep\bpa\bal\bli\biv\bve\be-\b-g\bga\bar\brb\bba\bag\bge\be _\bf_\bl_\ba_\bg;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn t\btc\bcp\bp-\b-k\bke\bee\bep\bpa\bal\bli\biv\bve\be-\b-i\bin\bnt\bte\ber\brv\bva\bal\bl _\bu_\bi_\bn_\bt_\b3_\b2;\b;
-
- 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)
-
-
- o\bop\bpt\bti\bio\bon\bn t\btf\bft\btp\bp-\b-s\bse\ber\brv\bve\ber\br-\b-n\bna\bam\bme\be _\bt_\be_\bx_\bt;\b;
-
- This option is used to identify a TFTP server and, if
- supported by the client, should have the same effect as
- the s\bse\ber\brv\bve\ber\br-\b-n\bna\bam\bme\be declaration. BOOTP clients are
- unlikely to support this option. Some DHCP clients
- will support it, and others actually require it.
-
- o\bop\bpt\bti\bio\bon\bn t\bti\bim\bme\be-\b-o\bof\bff\bfs\bse\bet\bt _\bi_\bn_\bt_\b3_\b2;\b;
-
- The time-offset option specifies the offset of the
- client's subnet in seconds from Coordinated Universal
- Time (UTC).
-
- o\bop\bpt\bti\bio\bon\bn t\bti\bim\bme\be-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- The time-server option specifies a list of RFC 868 time
- servers available to the client. Servers should be
- listed in order of preference.
-
- o\bop\bpt\bti\bio\bon\bn t\btr\bra\bai\bil\ble\ber\br-\b-e\ben\bnc\bca\bap\bps\bsu\bul\bla\bat\bti\bio\bon\bn _\bf_\bl_\ba_\bg;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn u\bua\bap\bp-\b-s\bse\ber\brv\bve\ber\brs\bs _\bt_\be_\bx_\bt;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn v\bve\ben\bnd\bdo\bor\br-\b-c\bcl\bla\bas\bss\bs-\b-i\bid\bde\ben\bnt\bti\bif\bfi\bie\ber\br _\bs_\bt_\br_\bi_\bn_\bg;\b;
-
- 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 v\bve\ben\bnd\bdo\bor\br-\b-e\ben\bnc\bca\bap\bps\bsu\bul\bla\bat\bte\bed\bd-\b-o\bop\bpt\bti\bio\bon\bns\bs option.
- Please see the VENDOR ENCAPSULATED OPTIONS section of
- the dhcpd.conf manual page for further information.
-
- o\bop\bpt\bti\bio\bon\bn v\bve\ben\bnd\bdo\bor\br-\b-e\ben\bnc\bca\bap\bps\bsu\bul\bla\bat\bte\bed\bd-\b-o\bop\bpt\bti\bio\bon\bns\bs _\bs_\bt_\br_\bi_\bn_\bg;\b;
-
- The v\bve\ben\bnd\bdo\bor\br-\b-e\ben\bnc\bca\bap\bps\bsu\bul\bla\bat\bte\bed\bd-\b-o\bop\bpt\bti\bio\bon\bns\bs 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 _\bd_\bh_\bc_\bp_\bd_\b._\bc_\bo_\bn_\bf _\bm_\ba_\bn_\bu_\ba_\bl
- _\bp_\ba_\bg_\be _\bf_\bo_\br _\bd_\be_\bt_\ba_\bi_\bl_\bs_\b.
-
- o\bop\bpt\bti\bio\bon\bn x\bx-\b-d\bdi\bis\bsp\bpl\bla\bay\by-\b-m\bma\ban\bna\bag\bge\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn w\bww\bww\bw-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- The WWW server option specifies a list of WWW available
- to the client. Servers should be listed in order of
- preference.
-
-R\bRE\bEL\bLA\bAY\bY A\bAG\bGE\bEN\bNT\bT I\bIN\bNF\bFO\bOR\bRM\bMA\bAT\bTI\bIO\bON\bN O\bOP\bPT\bTI\bIO\bON\bN
- 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.
-
- o\bop\bpt\bti\bio\bon\bn a\bag\bge\ben\bnt\bt.\b.c\bci\bir\brc\bcu\bui\bit\bt-\b-i\bid\bd _\bs_\bt_\br_\bi_\bn_\bg;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn a\bag\bge\ben\bnt\bt.\b.r\bre\bem\bmo\bot\bte\be-\b-i\bid\bd _\bs_\bt_\br_\bi_\bn_\bg;\b;
-
- 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.
-
-T\bTH\bHE\bE N\bNE\bET\bTW\bWA\bAR\bRE\bE/\b/I\bIP\bP S\bSU\bUB\bBO\bOP\bPT\bTI\bIO\bON\bNS\bS
- 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:
-
- o\bop\bpt\bti\bio\bon\bn n\bnw\bwi\bip\bp.\b.n\bns\bsq\bq-\b-b\bbr\bro\boa\bad\bdc\bca\bas\bst\bt _\bf_\bl_\ba_\bg;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn n\bnw\bwi\bip\bp.\b.p\bpr\bre\bef\bfe\ber\brr\bre\bed\bd-\b-d\bds\bss\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
-
- 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).
-
- o\bop\bpt\bti\bio\bon\bn n\bnw\bwi\bip\bp.\b.n\bne\bea\bar\bre\bes\bst\bt-\b-n\bnw\bwi\bip\bp-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
- [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs...];\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn n\bnw\bwi\bip\bp.\b.a\bau\but\bto\bor\bre\bet\btr\bri\bie\bes\bs _\bu_\bi_\bn_\bt_\b8;\b;
-
- Specifies the number of times that a NetWare/IP client
- should attempt to communicate with a given DSS server
- at startup.
-
- o\bop\bpt\bti\bio\bon\bn n\bnw\bwi\bip\bp.\b.a\bau\but\bto\bor\bre\bet\btr\bry\by-\b-s\bse\bec\bcs\bs _\bu_\bi_\bn_\bt_\b8;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn n\bnw\bwi\bip\bp.\b.n\bnw\bwi\bip\bp-\b-1\b1-\b-1\b1 _\bu_\bi_\bn_\bt_\b8;\b;
-
- 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.
-
- o\bop\bpt\bti\bio\bon\bn n\bnw\bwi\bip\bp.\b.p\bpr\bri\bim\bma\bar\bry\by-\b-d\bds\bss\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
-
- 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.
-
-D\bDE\bEF\bFI\bIN\bNI\bIN\bNG\bG N\bNE\bEW\bW O\bOP\bPT\bTI\bIO\bON\bNS\bS
- 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:
-
- o\bop\bpt\bti\bio\bon\bn _\bn_\be_\bw_\b-_\bn_\ba_\bm_\be c\bco\bod\bde\be _\bn_\be_\bw_\b-_\bc_\bo_\bd_\be =\b= _\bd_\be_\bf_\bi_\bn_\bi_\bt_\bi_\bo_\bn ;\b;
-
- The values of _\bn_\be_\bw_\b-_\bn_\ba_\bm_\be and _\bn_\be_\bw_\b-_\bc_\bo_\bd_\be should be the name you
- have chosen for the new option and the code you have cho
- sen. The _\bd_\be_\bf_\bi_\bn_\bi_\bt_\bi_\bo_\bn should be the definition of the
- structure of the option.
-
- The following simple option type definitions are sup
- ported:
-
- B\bBO\bOO\bOL\bLE\bEA\bAN\bN
-
- o\bop\bpt\bti\bio\bon\bn _\bn_\be_\bw_\b-_\bn_\ba_\bm_\be c\bco\bod\bde\be _\bn_\be_\bw_\b-_\bc_\bo_\bd_\be =\b= b\bbo\boo\bol\ble\bea\ban\bn ;\b;
-
- 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;
-
- I\bIN\bNT\bTE\bEG\bGE\bER\bR
-
- o\bop\bpt\bti\bio\bon\bn _\bn_\be_\bw_\b-_\bn_\ba_\bm_\be c\bco\bod\bde\be _\bn_\be_\bw_\b-_\bc_\bo_\bd_\be =\b= _\bs_\bi_\bg_\bn i\bin\bnt\bte\beg\bge\ber\br _\bw_\bi_\bd_\bt_\bh ;\b;
-
- The _\bs_\bi_\bg_\bn token should either be blank, _\bu_\bn_\bs_\bi_\bg_\bn_\be_\bd or _\bs_\bi_\bg_\bn_\be_\bd.
- 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;
-
- I\bIP\bP-\b-A\bAD\bDD\bDR\bRE\bES\bSS\bS
-
- o\bop\bpt\bti\bio\bon\bn _\bn_\be_\bw_\b-_\bn_\ba_\bm_\be c\bco\bod\bde\be _\bn_\be_\bw_\b-_\bc_\bo_\bd_\be =\b= i\bip\bp-\b-a\bad\bdd\bdr\bre\bes\bss\bs ;\b;
-
- 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;
-
-
- T\bTE\bEX\bXT\bT
-
- o\bop\bpt\bti\bio\bon\bn _\bn_\be_\bw_\b-_\bn_\ba_\bm_\be c\bco\bod\bde\be _\bn_\be_\bw_\b-_\bc_\bo_\bd_\be =\b= t\bte\bex\bxt\bt ;\b;
-
- 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";
-
-
- D\bDA\bAT\bTA\bA S\bST\bTR\bRI\bIN\bNG\bG
-
- o\bop\bpt\bti\bio\bon\bn _\bn_\be_\bw_\b-_\bn_\ba_\bm_\be c\bco\bod\bde\be _\bn_\be_\bw_\b-_\bc_\bo_\bd_\be =\b= s\bst\btr\bri\bin\bng\bg ;\b;
-
- 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;
-
-
- A\bAR\bRR\bRA\bAY\bYS\bS
-
- 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;
-
- R\bRE\bEC\bCO\bOR\bRD\bDS\bS
-
- 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;
-
-
-V\bVE\bEN\bND\bDO\bOR\bR E\bEN\bNC\bCA\bAP\bPS\bSU\bUL\bLA\bAT\bTE\bED\bD O\bOP\bPT\bTI\bIO\bON\bNS\bS
- The DHCP protocol defines the v\bve\ben\bnd\bdo\bor\br-\b-e\ben\bnc\bca\bap\bps\bsu\bul\bla\bat\bte\bed\bd-\b-o\bop\bpt\bti\bio\bon\bns\bs
- option, which allows vendors to define their own options
- that will be sent encapsulated in a standard DHCP option.
- The format of the v\bve\ben\bnd\bdo\bor\br-\b-e\ben\bnc\bca\bap\bps\bsu\bul\bla\bat\bte\bed\bd-\b-o\bop\bpt\bti\bio\bon\bns\bs 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 v\bve\ben\bnd\bdo\bor\br-\b-e\ben\bnc\bca\bap\bps\bsu\bul\bla\bat\bte\bed\bd-\b-
- o\bop\bpt\bti\bio\bon\bns\bs option.
-
- To define a new option space in which vendor options can
- be stored, use the option space statement:
-
- o\bop\bpt\bti\bio\bon\bn s\bsp\bpa\bac\bce\be _\bn_\ba_\bm_\be ;\b;
-
- 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 v\bve\ben\bnd\bdo\bor\br-\b-
- o\bop\bpt\bti\bio\bon\bn-\b-s\bsp\bpa\bac\bce\be declaration tells the DHCP server to use
- options in the SUNW option space to construct the v\bve\ben\bnd\bdo\bor\br-\b-
- e\ben\bnc\bca\bap\bps\bsu\bul\bla\bat\bte\bed\bd-\b-o\bop\bpt\bti\bio\bon\bns\bs option.
-
-S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-
- eval(5), dhcpd(8), dhclient(8), RFC2132, RFC2131, draft-
- ietf-dhc-agent-options-??.txt.
-
-A\bAU\bUT\bTH\bHO\bOR\bR
- The Internet Software Consortium DHCP Distribution was
- written by Ted Lemon <mellon@isc.org> 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
- h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 18
-
-
+++ /dev/null
-
-
-
-dhcpd(8) dhcpd(8)
-
-
-N\bNA\bAM\bME\bE
- dhcpd - Dynamic Host Configuration Protocol Server
-
-S\bSY\bYN\bNO\bOP\bPS\bSI\bIS\bS
- d\bdh\bhc\bcp\bpd\bd [ -\b-p\bp _\bp_\bo_\br_\bt ] [ -\b-f\bf ] [ -\b-d\bd ] [ -\b-q\bq ] [ -\b-t\bt | -\b-T\bT ] [ -\b-c\bcf\bf
- _\bc_\bo_\bn_\bf_\bi_\bg_\b-_\bf_\bi_\bl_\be ] [ -\b-l\blf\bf _\bl_\be_\ba_\bs_\be_\b-_\bf_\bi_\bl_\be ] [ _\bi_\bf_\b0 [ _\b._\b._\b._\bi_\bf_\bN ] ]
-
-D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
- 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.
-
-C\bCO\bON\bNT\bTR\bRI\bIB\bBU\bUT\bTI\bIO\bON\bNS\bS
- Development of this software is funded through contribu
- tions and support contracts. Please see d\bdh\bhc\bcp\bp-\b-c\bco\bon\bnt\btr\bri\bib\bb(\b(5\b5)\b)
- for information on how you can contribute.
-
-O\bOP\bPE\bER\bRA\bAT\bTI\bIO\bON\bN
- 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 _\bd_\bh_\bc_\bp_\bd_\b._\bc_\bo_\bn_\bf 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 _\bd_\bh_\bc_\bp_\bd_\b._\bl_\be_\ba_\bs_\be_\bs_\b~, 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
- _\b/_\bv_\ba_\br_\b/_\br_\bu_\bn_\b/_\bd_\bh_\bc_\bp_\bd_\b._\bp_\bi_\bd, 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.
-
-C\bCO\bOM\bMM\bMA\bAN\bND\bD L\bLI\bIN\bNE\bE
- 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 -\b-p\bp 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 -\b-f\bf 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 -\b-d\bd 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 -\b-c\bcf\bf flag, or an alternate lease file with the -\b-l\blf\bf
- flag. Because of the importance of using the same lease
- database at all times when running dhcpd in production,
- these options should be used o\bon\bnl\bly\by 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 -\b-q\bq flag may be specified.
-
- The DHCP server reads two files on startup: a configura
- tion file, and a lease database. If the -\b-t\bt 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 -\b-T\bT flag can be used to test the lease database file in
- a similar way.
-
-C\bCO\bON\bNF\bFI\bIG\bGU\bUR\bRA\bAT\bTI\bIO\bON\bN
- 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.
-
-
-S\bSu\bub\bbn\bne\bet\bts\bs
- 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.
-
-
-L\bLe\bea\bas\bse\be L\bLe\ben\bng\bgt\bth\bhs\bs
- 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.
-
-B\bBO\bOO\bOT\bTP\bP S\bSu\bup\bpp\bpo\bor\brt\bt
- 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";
- }
-
-O\bOp\bpt\bti\bio\bon\bns\bs
- 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).
-
-F\bFI\bIL\bLE\bES\bS
- /\b/e\bet\btc\bc/\b/d\bdh\bhc\bcp\bpd\bd.\b.c\bco\bon\bnf\bf,\b, /\b/v\bva\bar\br/\b/d\bdb\bb/\b/d\bdh\bhc\bcp\bpd\bd.\b.l\ble\bea\bas\bse\bes\bs,\b, /\b/v\bva\bar\br/\b/r\bru\bun\bn/\b/d\bdh\bhc\bcp\bpd\bd.\b.p\bpi\bid\bd,\b,
- /\b/v\bva\bar\br/\b/d\bdb\bb/\b/d\bdh\bhc\bcp\bpd\bd.\b.l\ble\bea\bas\bse\bes\bs~\b~.\b.
-
-S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5)
-
-A\bAU\bUT\bTH\bHO\bOR\bR
- d\bdh\bhc\bcp\bpd\bd(\b(8\b8)\b) was written by Ted Lemon <mellon@vix.com> 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
- h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 6
-
-
+++ /dev/null
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
-
-N\bNA\bAM\bME\bE
- dhcpd.conf - dhcpd configuration file
-
-D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
- The dhcpd.conf file contains configuration information for
- _\bd_\bh_\bc_\bp_\bd_\b, 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
- _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk and the _\bs_\bu_\bb_\bn_\be_\bt declarations. If clients
- on a subnet are to be assigned addresses dynamically, a
- _\br_\ba_\bn_\bg_\be declaration must appear within the _\bs_\bu_\bb_\bn_\be_\bt declara
- tion. For clients with statically assigned addresses, or
- for installations where only known clients will be served,
- each such client must have a _\bh_\bo_\bs_\bt declaration. If param
- eters are to be applied to a group of declarations which
- are not related strictly on a per-subnet basis, the _\bg_\br_\bo_\bu_\bp
- 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 _\bs_\bu_\bb_\bn_\be_\bt declaration, which tells dhcpd how to recognize
- that an address is on that subnet. A _\bs_\bu_\bb_\bn_\be_\bt 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 _\bs_\bu_\bb_\bn_\be_\bt declarations for these
- two networks may be enclosed in a _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk 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 _\bh_\bo_\bs_\bt declarations, these declara
- tions can be enclosed in a _\bg_\br_\bo_\bu_\bp 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 _\bh_\bo_\bs_\bt declaration
- (if any), and then consulting the any _\bc_\bl_\ba_\bs_\bs declarations
- matching the client, followed by the _\bp_\bo_\bo_\bl, _\bs_\bu_\bb_\bn_\be_\bt and
- _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk 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 _\bh_\bo_\bs_\bt declaration for a client,
- it first looks for a _\bh_\bo_\bs_\bt declaration which has a _\bf_\bi_\bx_\be_\bd_\b-
- _\ba_\bd_\bd_\br_\be_\bs_\bs 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 _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs 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.
-
-E\bEX\bXA\bAM\bMP\bPL\bLE\bES\bS
- A typical dhcpd.conf file will look something like this:
-
- _\bg_\bl_\bo_\bb_\ba_\bl _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
-
- subnet 204.254.239.0 netmask 255.255.255.224 {
- _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
- 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 {
- _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
- range 204.254.239.42 204.254.239.62;
- }
-
- subnet 204.254.239.64 netmask 255.255.255.224 {
- _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
- range 204.254.239.74 204.254.239.94;
- }
-
- group {
- _\bg_\br_\bo_\bu_\bp_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
- host zappo.test.isc.org {
- _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
- }
- host beppo.test.isc.org {
- _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
- }
- host harpo.test.isc.org {
- _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
- }
- }
-
- 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 _\bg_\br_\bo_\bu_\bp 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 _\bo_\bp_\bt_\bi_\bo_\bn keyword, some do not. Parameters starting
- with the _\bo_\bp_\bt_\bi_\bo_\bn 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 _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs.
- These could include such things as the _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option,
- the name of a file to upload (the _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\b) _\ba_\bn_\bd
- _\bt_\bh_\be _\ba_\bd_\bd_\br_\be_\bs_\bs _\bo_\bf _\bt_\bh_\be _\bs_\be_\br_\bv_\be_\br _\bf_\br_\bo_\bm _\bw_\bh_\bi_\bc_\bh _\bt_\bo _\bu_\bp_\bl_\bo_\ba_\bd _\bt_\bh_\be _\bf_\bi_\bl_\be
- _\b(_\bt_\bh_\be _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br 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; }
- }
-
-A\bAD\bDD\bDR\bRE\bES\bSS\bS P\bPO\bOO\bOL\bLS\bS
- The p\bpo\boo\bol\bl 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 _\ba_\bl_\bl_\bo_\bw or _\bd_\be_\bn_\by 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.
-
-A\bAD\bDD\bDR\bRE\bES\bSS\bS A\bAL\bLL\bLO\bOC\bCA\bAT\bTI\bIO\bON\bN
- 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 _\br_\ba_\bn_\bg_\be 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.
-
-C\bCL\bLI\bIE\bEN\bNT\bT C\bCL\bLA\bAS\bSS\bSI\bIN\bNG\bG
- 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 a\bad\bdd\bd
- 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 a\bad\bdd\bd 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.
-
-S\bSU\bUB\bBC\bCL\bLA\bAS\bSS\bSE\bES\bS
- 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.
-
-P\bPE\bER\bR-\b-C\bCL\bLA\bAS\bSS\bS L\bLI\bIM\bMI\bIT\bTS\bS O\bON\bN D\bDY\bYN\bNA\bAM\bMI\bIC\bC A\bAD\bDD\bDR\bRE\bES\bSS\bS A\bAL\bLL\bLO\bOC\bCA\bAT\bTI\bIO\bON\bN
- 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.
-
-S\bSP\bPA\bAW\bWN\bNI\bIN\bNG\bG C\bCL\bLA\bAS\bSS\bSE\bES\bS
- It is possible to declare a _\bs_\bp_\ba_\bw_\bn_\bi_\bn_\bg _\bc_\bl_\ba_\bs_\bs. 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 d\bdh\bhc\bcp\bpd\bd.\b.l\ble\bea\bas\bse\bes\bs 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.
-
-D\bDY\bYN\bNA\bAM\bMI\bIC\bC D\bDN\bNS\bS U\bUP\bPD\bDA\bAT\bTE\bES\bS
- 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 _\bd_\bd_\bn_\bs_\b-_\bd_\bo_\bm_\ba_\bi_\bn_\bn_\ba_\bm_\be and _\bd_\bd_\bn_\bs_\b-_\br_\be_\bv_\b-_\bd_\bo_\bm_\ba_\bi_\bn_\b
- _\bn_\ba_\bm_\be statements. The _\bd_\bd_\bn_\bs_\b-_\bd_\bo_\bm_\ba_\bi_\bn_\bn_\ba_\bm_\be 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 _\bd_\bd_\bn_\bs_\b-
- _\bd_\bo_\bm_\ba_\bi_\bn_\bn_\ba_\bm_\be is set to "sneedville.edu", then the client's
- FQDN will be "hutson.sneedville.edu".
-
- The _\bd_\bd_\bn_\bs_\b-_\br_\be_\bv_\b-_\bd_\bo_\bm_\ba_\bi_\bn_\bn_\ba_\bm_\be 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, _\bd_\bd_\bn_\bs_\b-_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be 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.
-
-H\bHO\bOW\bW D\bDN\bNS\bS U\bUP\bPD\bDA\bAT\bTE\bES\bS W\bWO\bOR\bRK\bK
- 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 _\bo_\bn_\be_\b-
- _\bl_\be_\ba_\bs_\be_\b-_\bp_\be_\br_\b-_\bc_\bl_\bi_\be_\bn_\bt 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.
-
-D\bDY\bYN\bNA\bAM\bMI\bIC\bC D\bDN\bNS\bS U\bUP\bPD\bDA\bAT\bTE\bE S\bSE\bEC\bCU\bUR\bRI\bIT\bTY\bY
- 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.
-
-R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: E\bEV\bVE\bEN\bNT\bTS\bS
- 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 o\bon\bn 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.
-
-R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: D\bDE\bEC\bCL\bLA\bAR\bRA\bAT\bTI\bIO\bON\bNS\bS
- T\bTh\bhe\be _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- s\bsh\bha\bar\bre\bed\bd-\b-n\bne\bet\btw\bwo\bor\brk\bk _\bn_\ba_\bm_\be {\b{
- [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
- [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
- }\b}
-
- The _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk 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 _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk statement. Parameters
- specified in the _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk 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.
-
- _\bN_\ba_\bm_\be 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.
-
- T\bTh\bhe\be _\bs_\bu_\bb_\bn_\be_\bt s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- s\bsu\bub\bbn\bne\bet\bt _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bn_\bu_\bm_\bb_\be_\br n\bne\bet\btm\bma\bas\bsk\bk _\bn_\be_\bt_\bm_\ba_\bs_\bk {\b{
- [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
- [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
- }\b}
-
- The _\bs_\bu_\bb_\bn_\be_\bt 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 _\br_\ba_\bn_\bg_\be declaration.
-
- The _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bn_\bu_\bm_\bb_\be_\br should be an IP address or domain name
- which resolves to the subnet number of the subnet being
- described. The _\bn_\be_\bt_\bm_\ba_\bs_\bk 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.
-
- T\bTh\bhe\be _\br_\ba_\bn_\bg_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- r\bra\ban\bng\bge\be [ d\bdy\byn\bna\bam\bmi\bic\bc-\b-b\bbo\boo\bot\btp\bp ] _\bl_\bo_\bw_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [ _\bh_\bi_\bg_\bh_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs];\b;
-
- For any subnet on which addresses will be assigned dynami
- cally, there must be at least one _\br_\ba_\bn_\bg_\be 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 _\br_\ba_\bn_\bg_\be statement is declared. The
- _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp 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, _\bh_\bi_\bg_\bh_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs can be omitted.
-
- T\bTh\bhe\be _\bh_\bo_\bs_\bt s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- h\bho\bos\bst\bt _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be {
- [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
- [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
- }\b}
-
- There must be at least one h\bho\bos\bst\bt statement for every BOOTP
- client that is to be served. h\bho\bos\bst\bt 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 _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
- parameter, or more than one h\bho\bos\bst\bt statement may be speci
- fied.
-
- If client-specific boot parameters must change based on
- the network to which the client is attached, then multiple
- h\bho\bos\bst\bt 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 h\bho\bos\bst\bt statement must be specified without a
- f\bfi\bix\bxe\bed\bd-\b-a\bad\bdd\bdr\bre\bes\bss\bs clause. _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be should be a name identify
- ing the host. If a _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option is not specified for
- the host, _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be is used.
-
- _\bH_\bo_\bs_\bt declarations are matched to actual DHCP or BOOTP
- clients by matching the dhcp-client-identifier option
- specified in the _\bh_\bo_\bs_\bt declaration to the one supplied by
- the client, or, if the _\bh_\bo_\bs_\bt declaration or the client does
- not provide a dhcp-client-identifier option, by matching
- the _\bh_\ba_\br_\bd_\bw_\ba_\br_\be parameter in the _\bh_\bo_\bs_\bt declaration to the net
- work hardware address supplied by the client. BOOTP
- clients do not normally provide a _\bd_\bh_\bc_\bp_\b-_\bc_\bl_\bi_\be_\bn_\bt_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br,
- so the hardware address must be used for all clients that
- may boot using the BOOTP protocol.
-
- T\bTh\bhe\be _\bg_\br_\bo_\bu_\bp s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- g\bgr\bro\bou\bup\bp {
- [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
- [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
- }\b}
-
- 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)
-
-
-R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: A\bAL\bLL\bLO\bOW\bW A\bAN\bND\bD D\bDE\bEN\bNY\bY
- The _\ba_\bl_\bl_\bo_\bw and _\bd_\be_\bn_\by 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 _\bi_\bg_\bn_\bo_\br_\be key
- word can be used in place of the _\bd_\be_\bn_\by keyword to prevent
- logging of denied requests.
-
-
-A\bAL\bLL\bLO\bOW\bW D\bDE\bEN\bNY\bY A\bAN\bND\bD I\bIG\bGN\bNO\bOR\bRE\bE I\bIN\bN S\bSC\bCO\bOP\bPE\bE
- The following usages of allow and deny will work in any
- scope, although it is not recommended that they be used in
- pool declarations.
-
- T\bTh\bhe\be _\bu_\bn_\bk_\bn_\bo_\bw_\bn_\b-_\bc_\bl_\bi_\be_\bn_\bt_\bs k\bke\bey\byw\bwo\bor\brd\bd
-
- a\bal\bll\blo\bow\bw u\bun\bnk\bkn\bno\bow\bwn\bn-\b-c\bcl\bli\bie\ben\bnt\bts\bs;\b;
- d\bde\ben\bny\by u\bun\bnk\bkn\bno\bow\bwn\bn-\b-c\bcl\bli\bie\ben\bnt\bts\bs;\b;
- i\big\bgn\bno\bor\bre\be u\bun\bnk\bkn\bno\bow\bwn\bn-\b-c\bcl\bli\bie\ben\bnt\bts\bs;\b;
-
- The u\bun\bnk\bkn\bno\bow\bwn\bn-\b-c\bcl\bli\bie\ben\bnt\bts\bs flag is used to tell dhcpd whether or
- not to dynamically assign addresses to unknown clients.
- Dynamic address assignment to unknown clients is a\bal\bll\blo\bow\bwed
- by default.
-
- T\bTh\bhe\be _\bb_\bo_\bo_\bt_\bp k\bke\bey\byw\bwo\bor\brd\bd
-
- a\bal\bll\blo\bow\bw b\bbo\boo\bot\btp\bp;\b;
- d\bde\ben\bny\by b\bbo\boo\bot\btp\bp;\b;
- i\big\bgn\bno\bor\bre\be b\bbo\boo\bot\btp\bp;\b;
-
- The b\bbo\boo\bot\btp\bp flag is used to tell dhcpd whether or not to
- respond to bootp queries. Bootp queries are a\bal\bll\blo\bow\bwed by
- default.
-
- T\bTh\bhe\be _\bb_\bo_\bo_\bt_\bi_\bn_\bg k\bke\bey\byw\bwo\bor\brd\bd
-
- a\bal\bll\blo\bow\bw b\bbo\boo\bot\bti\bin\bng\bg;\b;
- d\bde\ben\bny\by b\bbo\boo\bot\bti\bin\bng\bg;\b;
- i\big\bgn\bno\bor\bre\be b\bbo\boo\bot\bti\bin\bng\bg;\b;
-
- The b\bbo\boo\bot\bti\bin\bng\bg 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 a\bal\bll\blo\bow\bwed, but if it is disabled for
- a particular client, then that client will not be able to
- get and address from the DHCP server. T\bTh\bhe\be _\bd_\bu_\bp_\bl_\bi_\bc_\ba_\bt_\be_\bs k\bke\bey\by\b
- w\bwo\bor\brd\bd
-
- a\bal\bll\blo\bow\bw d\bdu\bup\bpl\bli\bic\bca\bat\bte\bes\bs;\b;
-
-
-
- 16
-
-
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
-
- d\bde\ben\bny\by d\bdu\bup\bpl\bli\bic\bca\bat\bte\bes\bs;\b;
-
- 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 d\bdu\bup\bpl\bli\bic\bca\bat\bte\bes\bs 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 a\bal\bll\blo\bow\bwed. T\bTh\bhe\be
- _\bd_\be_\bc_\bl_\bi_\bn_\be_\bs k\bke\bey\byw\bwo\bor\brd\bd
-
- a\bal\bll\blo\bow\bw d\bde\bec\bcl\bli\bin\bne\bes\bs;\b;
- d\bde\ben\bny\by d\bde\bec\bcl\bli\bin\bne\bes\bs;\b;
- i\big\bgn\bno\bor\bre\be d\bde\bec\bcl\bli\bin\bne\bes\bs;\b;
-
- 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 d\bde\bec\bcl\bli\bin\bne\bes\bs flag tells the DHCP server whether or not to
- honor DHCPDECLINE messages. If it is set to d\bde\ben\bny\by or
- i\big\bgn\bno\bor\bre\be in a particular scope, the DHCP server will not
- respond to DHCPDECLINE messages.
-
-A\bAL\bLL\bLO\bOW\bW A\bAN\bND\bD D\bDE\bEN\bNY\bY W\bWI\bIT\bTH\bHI\bIN\bN P\bPO\bOO\bOL\bL D\bDE\bEC\bCL\bLA\bAR\bRA\bAT\bTI\bIO\bON\bNS\bS
- 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:
-
- k\bkn\bno\bow\bwn\bn c\bcl\bli\bie\ben\bnt\bts\bs;\b;
-
- 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 _\ba_\bn_\by scope, not just the current
- scope.
-
- u\bun\bnk\bkn\bno\bow\bwn\bn c\bcl\bli\bie\ben\bnt\bts\bs;\b;
-
- 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).
-
- m\bme\bem\bmb\bbe\ber\brs\bs o\bof\bf "\b"class"\b";\b;
-
- If specified, this statement either allows or prevents
- allocation from this pool to any client that is a member
- of the named class.
-
- d\bdy\byn\bna\bam\bmi\bic\bc b\bbo\boo\bot\btp\bp c\bcl\bli\bie\ben\bnt\bts\bs;\b;
-
- If specified, this statement either allows or prevents
- allocation from this pool to any bootp client.
-
- a\bau\but\bth\bhe\ben\bnt\bti\bic\bca\bat\bte\bed\bd c\bcl\bli\bie\ben\bnt\bts\bs;\b;
-
- 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.
-
- u\bun\bna\bau\but\bth\bhe\ben\bnt\bti\bic\bca\bat\bte\bed\bd c\bcl\bli\bie\ben\bnt\bts\bs;\b;
-
- 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.
-
- a\bal\bll\bl c\bcl\bli\bie\ben\bnt\bts\bs;\b;
-
- 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.
-
-R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: P\bPA\bAR\bRA\bAM\bME\bET\bTE\bER\bRS\bS
- T\bTh\bhe\be _\bl_\be_\ba_\bs_\be_\b-_\bf_\bi_\bl_\be_\b-_\bn_\ba_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- l\ble\bea\bas\bse\be-\b-f\bfi\bil\ble\be-\b-n\bna\bam\bme\be _\bn_\ba_\bm_\be;\b;
-
- _\bN_\ba_\bm_\be should be the name of the DHCP server's lease file.
- By default, this is /var/db/dhcpd.leases. This statement
- m\bmu\bus\bst\bt appear in the outer scope of the configuration file -
- if it appears in some other scope, it will have no effect.
-
- T\bTh\bhe\be _\bp_\bi_\bd_\b-_\bf_\bi_\bl_\be_\b-_\bn_\ba_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- p\bpi\bid\bd-\b-f\bfi\bil\ble\be-\b-n\bna\bam\bme\be _\bn_\ba_\bm_\be;\b;
-
- _\bN_\ba_\bm_\be 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.
-
- T\bTh\bhe\be _\bd_\be_\bf_\ba_\bu_\bl_\bt_\b-_\bl_\be_\ba_\bs_\be_\b-_\bt_\bi_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- d\bde\bef\bfa\bau\bul\blt\bt-\b-l\ble\bea\bas\bse\be-\b-t\bti\bim\bme\be _\bt_\bi_\bm_\be;\b;
-
- _\bT_\bi_\bm_\be 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.
-
- T\bTh\bhe\be _\bm_\ba_\bx_\b-_\bl_\be_\ba_\bs_\be_\b-_\bt_\bi_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- m\bma\bax\bx-\b-l\ble\bea\bas\bse\be-\b-t\bti\bim\bme\be _\bt_\bi_\bm_\be;\b;
-
- _\bT_\bi_\bm_\be 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.
-
- T\bTh\bhe\be _\bm_\bi_\bn_\b-_\bl_\be_\ba_\bs_\be_\b-_\bt_\bi_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- m\bmi\bin\bn-\b-l\ble\bea\bas\bse\be-\b-t\bti\bim\bme\be _\bt_\bi_\bm_\be;\b;
-
- _\bT_\bi_\bm_\be should be the minimum length in seconds that will be
- assigned to a lease.
-
- T\bTh\bhe\be _\bm_\bi_\bn_\b-_\bs_\be_\bc_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- m\bmi\bin\bn-\b-s\bse\bec\bcs\bs _\bs_\be_\bc_\bo_\bn_\bd_\bs;\b;
-
- _\bS_\be_\bc_\bo_\bn_\bd_\bs 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.
-
- T\bTh\bhe\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- h\bha\bar\brd\bdw\bwa\bar\bre\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\bt_\by_\bp_\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
-
- In order for a BOOTP client to be recognized, its network
- hardware address must be declared using a _\bh_\ba_\br_\bd_\bw_\ba_\br_\be clause
- in the _\bh_\bo_\bs_\bt statement. _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\bt_\by_\bp_\be must be the name of
- a physical hardware interface type. Currently, only the
- e\bet\bth\bhe\ber\brn\bne\bet\bt and t\bto\bok\bke\ben\bn-\b-r\bri\bin\bng\bg types are recognized, although
- support for a f\bfd\bdd\bdi\bi hardware type (and others) would also
- be desirable. The _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs should be a set of
- hexadecimal octets (numbers from 0 through ff) seperated
- by colons. The _\bh_\ba_\br_\bd_\bw_\ba_\br_\be statement may also be used for
- DHCP clients.
-
- T\bTh\bhe\be _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- f\bfi\bil\ble\ben\bna\bam\bme\be "\b"_\bf_\bi_\bl_\be_\bn_\ba_\bm_\be"\b";\b;
-
- The _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be 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 _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be should be a filename recognizable to whatever
- file transfer protocol the client can be expected to use
- to load the file.
-
- T\bTh\bhe\be _\bs_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- s\bse\ber\brv\bve\ber\br-\b-n\bna\bam\bme\be "\b"_\bn_\ba_\bm_\be"\b";\b;
-
- The _\bs_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be statement can be used to inform the client
- of the name of the server from which it is booting. _\bN_\ba_\bm_\be
- should be the name that will be provided to the client.
-
- T\bTh\bhe\be _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- n\bne\bex\bxt\bt-\b-s\bse\ber\brv\bve\ber\br _\bs_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be;\b;
-
- The _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br statement is used to specify the host
- address of the server from which the initial boot file
- (specified in the _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be statement) is to be loaded.
- _\bS_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be should be a numeric IP address or a domain
- name. If no _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br parameter applies to a given
- client, the DHCP server's IP address is used.
-
- T\bTh\bhe\be _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- f\bfi\bix\bxe\bed\bd-\b-a\bad\bdd\bdr\bre\bes\bss\bs _\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\ba_\bd_\bd_\br_\be_\bs_\bs ... ];\b;
-
- The _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs statement is used to assign one or more
- fixed IP addresses to a client. It should only appear in
- a _\bh_\bo_\bs_\bt 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 _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
- statement are on the network on which the client is boot
- ing, that client will not match the _\bh_\bo_\bs_\bt declaration con
- taining that _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs statement. Each _\ba_\bd_\bd_\br_\be_\bs_\bs should
- be either an IP address or a domain name which resolves to
- one or more IP addresses.
-
- T\bTh\bhe\be _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bc_\bu_\bt_\bo_\bf_\bf s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- d\bdy\byn\bna\bam\bmi\bic\bc-\b-b\bbo\boo\bot\btp\bp-\b-l\ble\bea\bas\bse\be-\b-c\bcu\but\bto\bof\bff\bf _\bd_\ba_\bt_\be;\b;
-
- The _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bc_\bu_\bt_\bo_\bf_\bf 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.
-
- _\bD_\ba_\bt_\be 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.
-
- T\bTh\bhe\be _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bl_\be_\bn_\bg_\bt_\bh s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- d\bdy\byn\bna\bam\bmi\bic\bc-\b-b\bbo\boo\bot\btp\bp-\b-l\ble\bea\bas\bse\be-\b-l\ble\ben\bng\bgt\bth\bh _\bl_\be_\bn_\bg_\bt_\bh;\b;
-
- The _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bl_\be_\bn_\bg_\bt_\bh 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 _\bl_\be_\bn_\bg_\bt_\bh as a num
- ber of seconds. If a client reboots using BOOTP during
- the timeout period, the lease duration is reset to _\bl_\be_\bn_\bg_\bt_\bh,
- so a BOOTP client that boots frequently enough will never
- lose its lease. Needless to say, this parameter should be
- adjusted with extreme caution.
-
- T\bTh\bhe\be _\bg_\be_\bt_\b-_\bl_\be_\ba_\bs_\be_\b-_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- g\bge\bet\bt-\b-l\ble\bea\bas\bse\be-\b-h\bho\bos\bst\btn\bna\bam\bme\bes\bs _\bf_\bl_\ba_\bg;\b;
-
- The _\bg_\be_\bt_\b-_\bl_\be_\ba_\bs_\be_\b-_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be_\bs 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 _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option. If _\bf_\bl_\ba_\bg is
- true, then this lookup is done for all addresses in the
- current scope. By default, or if _\bf_\bl_\ba_\bg is false, no
- lookups are done.
-
- T\bTh\bhe\be _\bu_\bs_\be_\b-_\bh_\bo_\bs_\bt_\b-_\bd_\be_\bc_\bl_\b-_\bn_\ba_\bm_\be_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- u\bus\bse\be-\b-h\bho\bos\bst\bt-\b-d\bde\bec\bcl\bl-\b-n\bna\bam\bme\bes\bs _\bf_\bl_\ba_\bg;\b;
-
- If the _\bu_\bs_\be_\b-_\bh_\bo_\bs_\bt_\b-_\bd_\be_\bc_\bl_\b-_\bn_\ba_\bm_\be_\bs 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 _\bo_\bp_\bt_\bi_\bo_\bn _\bh_\bo_\bs_\bt_\b-_\bn_\ba_\bm_\be statement within a host declaration
- will override the use of the name in the host declaration.
-
- T\bTh\bhe\be _\ba_\bu_\bt_\bh_\bo_\br_\bi_\bt_\ba_\bt_\bi_\bv_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- a\bau\but\bth\bho\bor\bri\bit\bta\bat\bti\biv\bve\be;\b;
-
- n\bno\bot\bt a\bau\but\bth\bho\bor\bri\bit\bta\bat\bti\biv\bve\be;\b;
-
- 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 a\bau\but\bth\bho\bor\bri\bit\bta\ba\b
- t\bti\biv\bve\be;\b; at the top of their configuration file to indicate
- that the DHCP server _\bs_\bh_\bo_\bu_\bl_\bd 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 a\bau\but\bth\bho\bor\bri\bit\bta\bat\bti\biv\bve\be;\b; 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)
-
-
- T\bTh\bhe\be _\ba_\bl_\bw_\ba_\by_\bs_\b-_\br_\be_\bp_\bl_\by_\b-_\br_\bf_\bc_\b1_\b0_\b4_\b8 s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- a\bal\blw\bwa\bay\bys\bs-\b-r\bre\bep\bpl\bly\by-\b-r\brf\bfc\bc1\b10\b04\b48\b8 _\bf_\bl_\ba_\bg;\b;
-
- 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 a\bal\blw\bwa\bay\bys\bs-\b-r\bre\bep\bpl\bly\by-\b-r\brf\bfc\bc1\b10\b04\b48\b8 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.
-
- T\bTh\bhe\be _\ba_\bl_\bw_\ba_\by_\bs_\b-_\bb_\br_\bo_\ba_\bd_\bc_\ba_\bs_\bt s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- a\bal\blw\bwa\bay\bys\bs-\b-b\bbr\bro\boa\bad\bdc\bca\bas\bst\bt _\bf_\bl_\ba_\bg;\b;
-
- 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.
-
- T\bTh\bhe\be _\bo_\bn_\be_\b-_\bl_\be_\ba_\bs_\be_\b-_\bp_\be_\br_\b-_\bc_\bl_\bi_\be_\bn_\bt s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- o\bon\bne\be-\b-l\ble\bea\bas\bse\be-\b-p\bpe\ber\br-\b-c\bcl\bli\bie\ben\bnt\bt _\bf_\bl_\ba_\bg;\b;
-
- 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 _\ba_\bn_\bd
- 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.
-
- T\bTh\bhe\be _\bu_\bs_\be_\b-_\bl_\be_\ba_\bs_\be_\b-_\ba_\bd_\bd_\br_\b-_\bf_\bo_\br_\b-_\bd_\be_\bf_\ba_\bu_\bl_\bt_\b-_\br_\bo_\bu_\bt_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- u\bus\bse\be-\b-l\ble\bea\bas\bse\be-\b-a\bad\bdd\bdr\br-\b-f\bfo\bor\br-\b-d\bde\bef\bfa\bau\bul\blt\bt-\b-r\bro\bou\but\bte\be _\bf_\bl_\ba_\bg;\b;
-
-
-
-
- 24
-
-
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
-
- If the _\bu_\bs_\be_\b-_\bl_\be_\ba_\bs_\be_\b-_\ba_\bd_\bd_\br_\b-_\bf_\bo_\br_\b-_\bd_\be_\bf_\ba_\bu_\bl_\bt_\b-_\br_\bo_\bu_\bt_\be 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.
-
- T\bTh\bhe\be _\bs_\be_\br_\bv_\be_\br_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- s\bse\ber\brv\bve\ber\br-\b-i\bid\bde\ben\bnt\bti\bif\bfi\bie\ber\br _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be;\b;
-
- 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 m\bmu\bus\bst\bt 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 _\bs_\be_\br_\bv_\be_\br_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br 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.
-
- T\bTh\bhe\be _\bd_\bd_\bn_\bs_\b-_\bu_\bp_\bd_\ba_\bt_\be_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-
- d\bdd\bdn\bns\bs-\b-u\bup\bpd\bda\bat\bte\bes\bs _\bf_\bl_\ba_\bg;\b;
-
- The _\bd_\bd_\bn_\bs_\b-_\bu_\bp_\bd_\ba_\bt_\be_\bs parameter controls whether or not the
- server will attempt to do a ddns update when a lease is
- confirmed. Set this to _\bo_\bf_\bf if the server should not
- attempt to do updates within a certain scope. The _\bd_\bd_\bn_\bs_\b-
- _\bu_\bp_\bd_\ba_\bt_\be_\bs parameter is on by default.
-
-R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: O\bOP\bPT\bTI\bIO\bON\bN S\bST\bTA\bAT\bTE\bEM\bME\bEN\bNT\bTS\bS
- DHCP option statements are documented in the d\bdh\bhc\bcp\bp-\b-
- o\bop\bpt\bti\bio\bon\bns\bs(\b(5\b5)\b) manual page.
-
-S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131.
-
-
-
-
- 25
-
-
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
-
-A\bAU\bUT\bTH\bHO\bOR\bR
- d\bdh\bhc\bcp\bpd\bd(\b(8\b8)\b) was written by Ted Lemon <mellon@vix.com> 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
- h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 26
-
-
+++ /dev/null
-
-
-
-dhcpd.leases(5) dhcpd.leases(5)
-
-
-N\bNA\bAM\bME\bE
- dhcpd.leases - DHCP client lease database
-
-D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
- 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. D\bDO\bO N\bNO\bOT\bT 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.
-
-F\bFO\bOR\bRM\bMA\bAT\bT
- Lease descriptions are stored in a format that is parsed
- by the same recursive descent parser used to read the
- d\bdh\bhc\bcp\bpd\bd.\b.c\bco\bon\bnf\bf(\b(5\b5)\b) and d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.c\bco\bon\bnf\bf(\b(5\b5)\b) files. Currently, the
- only declaration that is used in the dhcpd.leases file is
- the l\ble\bea\bas\bse\be declaration.
-
- l\ble\bea\bas\bse\be _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs {\b{ _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt_\bs_\b._\b._\b. }\b}
-
- 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)
-
-
- s\bst\bta\bar\brt\bts\bs _\bd_\ba_\bt_\be;\b;
- e\ben\bnd\bds\bs _\bd_\ba_\bt_\be;\b;
-
- Dates are specified as follows:
-
- _\bw_\be_\be_\bk_\bd_\ba_\by _\by_\be_\ba_\br/\b/_\bm_\bo_\bn_\bt_\bh/\b/_\bd_\ba_\by _\bh_\bo_\bu_\br:\b:_\bm_\bi_\bn_\bu_\bt_\be:\b:_\bs_\be_\bc_\bo_\bn_\bd
-
- 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 d\bda\bat\bte\be -\b-u\bu.
-
- The MAC address of the network interface that was used to
- acquire the lease is recorded with the h\bha\bar\brd\bdw\bwa\bar\bre\be statement:
-
- h\bha\bar\brd\bdw\bwa\bar\bre\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\bt_\by_\bp_\be _\bm_\ba_\bc_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
-
- 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 u\bui\bid\bd
- statement:
-
- u\bui\bid\bd _\bc_\bl_\bi_\be_\bn_\bt_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br;\b;
-
- 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 _\bC_\bl_\bi_\be_\bn_\bt _\bH_\bo_\bs_\bt_\bn_\ba_\bm_\be
- option, as specified in some versions of the DHCP-DNS
- Interaction draft, that hostname is recorded using the
- c\bcl\bli\bie\ben\bnt\bt-\b-h\bho\bos\bst\btn\bna\bam\bme\be statement.
-
- c\bcl\bli\bie\ben\bnt\bt-\b-h\bho\bos\bst\btn\bna\bam\bme\be "\b"_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be"\b";\b;
-
- If the client sends its hostname using the _\bH_\bo_\bs_\bt_\bn_\ba_\bm_\be
- option, as Windows 95 does, it is recorded using the
-
-
-
- 2
-
-
-
-
-
-dhcpd.leases(5) dhcpd.leases(5)
-
-
- h\bho\bos\bst\btn\bna\bam\bme\be statement.
-
- h\bho\bos\bst\btn\bna\bam\bme\be "\b"_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be"\b";\b;
-
- 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 a\bab\bba\ban\bnd\bdo\bon\bne\bed\bd statement will be used to indi
- cate that the lease should not be reassigned.
-
- a\bab\bba\ban\bnd\bdo\bon\bne\bed\bd;\b;
-
- 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 r\bre\beq\bqu\bue\bes\bst\bts\bs 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.
-
-F\bFI\bIL\bLE\bES\bS
- /\b/v\bva\bar\br/\b/d\bdb\bb/\b/d\bdh\bhc\bcp\bpd\bd.\b.l\ble\bea\bas\bse\bes\bs
-
-S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132,
- RFC2131.
-
-A\bAU\bUT\bTH\bHO\bOR\bR
- d\bdh\bhc\bcp\bpd\bd(\b(8\b8)\b) was written by Ted Lemon <mellon@vix.com> 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 h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 3
-
-
projects / thirdparty / dhcp.git / commitdiff
