Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
dhcpd.leases(5)		      File Formats Manual	       dhcpd.leases(5)

NAME
       dhcpd.leases - DHCP client lease	database

DESCRIPTION
       The Internet Systems Consortium DHCP Server keeps a persistent 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
       DBDIR/dhcpd.leases.   You can do	this with:

	    touch DBDIR/dhcpd.leases

       In order	to prevent the lease database from growing without bound,  the
       file  is	 rewritten from	time to	time.	First, a temporary lease data-
       base is created and all known leases are	dumped to it.	Then, the  old
       lease  database	is  renamed  DBDIR/dhcpd.leases~.   Finally, the newly
       written lease database is moved into place.

       In order	to process both	DHCPv4 and DHCPv6 messages you	will  need  to
       run  two	 separate  instances  of the dhcpd process.  Each of these in-
       stances will need it's own lease	file.  You can use the -lf  option  on
       the  server's  command  line to specify a different lease file name for
       one or both servers.

FORMAT
       Lease descriptions are stored in	a format that is parsed	 by  the  same
       recursive   descent   parser   used   to	 read  the  dhcpd.conf(5)  and
       dhclient.conf(5)	files.	Lease files can	 contain  lease	 declarations,
       and  also  group	 and  subgroup	declarations,  host  declarations  and
       failover	state declarations.  Group, subgroup and host declarations are
       used to record objects created using the	OMAPI protocol.

       The lease file is a log-structured file - whenever a lease changes, the
       contents	of that	lease are written to the end of	the file.   This means
       that it is entirely possible and	quite reasonable for there to  be  two
       or  more	 declarations  of the same lease in the	lease file at the same
       time.   In that case, the instance of that particular  lease  that  ap-
       pears last in the file is the one that is in effect.

       Group,  subgroup	and host declarations in the lease file	are handled in
       the same	manner,	except that if any of these  objects  are  deleted,  a
       rubout  is  written to the lease	file.	This is	just the same declara-
       tion, with { deleted; } in the scope of	the  declaration.    When  the
       lease  file  is	rewritten, any such rubouts that can be	eliminated are
       eliminated.   It	is possible to delete a	declaration in the  dhcpd.conf
       file;  in  this	case,  the  rubout  can	 never	be eliminated from the
       dhcpd.leases file.

COMMON STATEMENTS FOR LEASE DECLARATIONS
       While the lease file formats for	DHCPv4 and DHCPv6 are  different  they
       share  many  common  statements and structures.	This section describes
       the common statements while the succeeding sections describe the	proto-
       col specific statements.

       Dates

       A date is specified in two ways,	depending on the  configuration	 value
       for  the	 db-time-format	parameter.  If it was set to default, then the
       date fields appear as follows:

       weekday year/month/day hour:minute:second

       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  re-
       ally  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 second	also a number between 0	and 59.

       Lease times are specified in Universal Coordinated Time (UTC),  not  in
       the  local time zone.  There is probably	nowhere	in the world where the
       times recorded on a lease are always the	same as	wall clock times.   On
       most  unix  machines, you can display the current time in UTC by	typing
       date -u.

       If the db-time-format was configured to local, then the date fields ap-
       pear as follows:

	epoch <seconds-since-epoch>; #	<day-name>  <month-name>  <day-number>
       <hours>:<minutes>:<seconds> <year>

       The  seconds-since-epoch	 is  as	 according to the system's local clock
       (often referred to as "unix time").  The	# symbol  supplies  a  comment
       that  describes	what  actual time this is as according to the system's
       configured timezone, at the time	the value was written.	It is provided
       only for	human inspection.

       If a lease will never expire, date is never instead of an actual	date.

       General Variables

       As part of the processing of a lease information	may be attached	to the
       lease structure,	for example the	DDNS information or if you  specify  a
       variable	 in your configuration file.  Some of these, like the DDNS in-
       formation, have specific	descriptions below.  For others, such  as  any
       you might define, a generic line	of the following will be included.

       set variable = value;

       The  set	statement sets the value of a variable on the lease.  For gen-
       eral information	on variables, see the dhcp-eval(5) manual page.

       DDNS Variables

       The ddns-text and ddns-dhcid variables

       These variables are used	to record the value of the client's identification
       record when the server has updated DNS for a particular lease.  The text
       record is used with the interim DDNS update style while the dhcid record
       is used for the standard	DDNS update style.

       The ddns-fwd-name variable

       This variable records the value of the name used	in
       updating	the client's A record if a DDNS	update has been	successfully
       done by the server.   The server	may also have used this	name to
       update the client's PTR record.

       The ddns-client-fqdn variable

       If the server is	configured both	to use the interim or standard DDNS update
       style, and to allow clients to update their own FQDNs, then if the
       client did in fact update its own FQDN, the
       ddns-client-fqdn	variable records the name that the client has
       indicated it is using.	This is	the name that the server will have
       used to update the client's PTR record in this case.

       The ddns-rev-name variable

       If the server successfully updates the client's PTR record, this
       variable	will record the	name that the DHCP server used for the PTR
       record.	 The name to which the PTR record points will be either	the
       ddns-fwd-name or	the ddns-client-fqdn.

       Executable Statements

       on events { statements... }
       The on statement	records	a list of statements to	execute	if a
       certain event occurs.   The possible events that	can occur for an
       active lease are	release	and expiry.   More than	one event
       can be specified	- if so, the events are	separated by '|' characters.

       The authoring-byte-order	statement

	 authoring-byte-order [	big-endian | little-endian ] ;

	 This statement	is automatically added to the top of new lease files by
	 the server. It	indicates the internal byte order of the server.  This
	 permits lease files generated on a server with	one form of byte order
	 to be read by a server	with a different form.	Lease files which do not
	 contain this entry are	simply treated as having the same byte order as
	 the server reading them.  If you are migrating	lease files generated
	 by a server that predates this	statement and is of a different	byte
	 order than the	your destination server, you can manually add this
	 statement.  It	must proceed any lease entries.	 Valid values for this
	 parameter are little-endian and big-endian.

THE DHCPv4 LEASE DECLARATION
       lease ip-address	{ statements...	}

       Each lease declaration includes the single IP  address  that  has  been
       leased to the client.   The statements within the braces	define the du-
       ration of the lease and to whom it is assigned.

       starts date;
       ends date;
       tstp date;
       tsfp date;
       atsfp date;
       cltt date;

       The  start  and	end  time of a lease are recorded using	the starts and
       ends statements.	  The tstp statement is	present	if the failover	proto-
       col is being used, and indicates	what time the peer has been  told  the
       lease  expires.	  The  tsfp  statement is also present if the failover
       protocol	is being used, and indicates the lease expiry  time  that  the
       peer  has  acknowledged.	  The  atsfp statement is the actual time sent
       from the	failover partner.  The cltt statement  is  the	client's  last
       transaction time.

       See the description of dates in the section on common structures.

       hardware	hardware-type mac-address;

       The hardware statement records the MAC address of the network interface
       on which	the lease will be used.	  It is	specified as a series of hexa-
       decimal octets, separated by colons.

       uid client-identifier;

       The  uid	 statement records the client identifier used by the client to
       acquire the lease.   Clients are	not required to	 send  client  identi-
       fiers,  and  this statement only	appears	if the client did in fact send
       one.   Client identifiers are normally an ARP  type  (1	for  ethernet)
       followed	 by  the MAC address, just like	in the hardware	statement, but
       this is not required.

       The client identifier is	recorded as a colon-separated hexadecimal list
       or as a quoted string.	If it is recorded as a quoted  string  and  it
       contains	 one  or  more	non-printable characters, those	characters are
       represented as octal escapes - a	backslash character followed by	 three
       octal digits.  The format used is determined by the lease-id-format pa-
       rameter,	which defaults to octal.

       client-hostname hostname	;

       Most DHCP clients will send their hostname in the host-name option.  If
       a  client  sends	 its hostname in this way, the hostname	is recorded on
       the lease with a	client-hostname	statement.   This is not  required  by
       the  protocol,  however,	so many	specialized DHCP clients do not	send a
       host-name option.

       binding state state;
       next binding state state;

       The binding state statement declares the	lease's	binding	 state.	  When
       the  DHCP  server  is  not  configured  to use the failover protocol, a
       lease's binding state may be active, free or abandoned.	 The  failover
       protocol	 adds  some  additional	 transitional  states,	as well	as the
       backup state, which indicates that the lease is available  for  alloca-
       tion  by	 the  failover	secondary. Please see the dhcpd.conf(5)	manual
       page for	more information about abandoned leases.

       The next	binding	state statement	indicates what state  the  lease  will
       move  to	 when  the  current state expires.   The time when the current
       state expires is	specified in the ends statement.

       rewind binding state state;

       This statement is part of an optimization for use with failover.	  This
       helps a server rewind a lease to	the state most recently	transmitted to
       its peer.

       option agent.circuit-id string;
       option agent.remote-id string;

       These  statements  are  used to record the circuit ID and remote	ID op-
       tions sent by the relay agent, if the relay agent uses the relay	 agent
       information option.   This allows these options to be used consistently
       in  conditional	evaluations  even  when	 the  client is	contacting the
       server directly rather than through its relay agent.

       The vendor-class-identifier variable

       The server retains the client-supplied Vendor Class  Identifier	option
       for  informational  purposes,  and to render them in DHCPLEASEQUERY re-
       sponses.

       bootp;
       reserved;

       If present, they	indicate that the BOOTP	and  RESERVED  failover	 flags
       (respectively)  should  be  set.	 BOOTP and RESERVED dynamic leases are
       treated differently than	normal dynamic leases, as  they	 may  only  be
       used by the client to which they	are currently allocated.

       Other  Additional options or executable statements may be included, see
       the description of them in the section on common	structures.

THE DHCPv6 LEASE (IA) DECLARATION
       ia_ta  IAID_DUID	{ statements...	}
       ia_na  IAID_DUID	{ statements...	}
       ia_pd  IAID_DUID	{ statements...	}

       Each lease declaration starts with a tag	indicating  the	 type  of  the
       lease.	ia_ta  is  for temporary addresses, ia_na is for non-temporary
       addresses and ia_pd is for prefix delegation.  Following	 this  tag  is
       the combined IAID and DUID from the client for this lease.

       The  IAID_DUID  value is	recorded as a colon-separated hexadecimal list
       or as a quoted string.	If it is recorded as a quoted  string  and  it
       contains	 one  or  more	non-printable characters, those	characters are
       represented as octal escapes - a	backslash character followed by	 three
       octal digits.  The format used is governed by the lease-id-format para-
       meter, which defaults to	octal.

       cltt date;

       The cltt	statement is the client's last transaction time.

       See the description of dates in the section on common structures.

       iaaddr ipv6-address { statements... }
       iaprefix	ipv6-address/prefix-length { statements... }

       Within a	given lease there can be multiple iaaddr and iaprefix statements.
       Each will have either an	IPv6 address or	an IPv6	prefix (an address and
       a prefix	length indicating a CIDR style block of	addresses).  The following
       statements may occur Within each	iaaddr or iaprefix.

       binding state state;

       The binding state statement declares the	lease's	binding	state.
       In DHCPv6 you will normally see this as active or expired.

       preferred-life lifetime;

       The IPv6	preferred lifetime associated with this	address, in seconds.

       max-life	lifetime;

       The valid lifetime associated with this address,	in seconds.

       ends date;

       The end time of the lease.  See the description of dates	in the section on
       common structures.

       Additional options or executable	statements may be included.  See the description
       of them in the section on common	structures.

THE FAILOVER PEER STATE	DECLARATION
       The  state of any failover peering arrangements is also recorded	in the
       lease file, using the failover peer statement:

       failover	peer name state	{
       my state	state at date;
       peer state state	at date;
       }

       The states of the peer named name is being recorded.   Both  the	 state
       of  the	running	server (my state) and the other	failover partner (peer
       state) are recorded.   The  following  states  are  possible:  unknown-
       state, partner-down, normal, communications-interrupted,	resolution-in-
       terrupted, potential-conflict, recover, recover-done, shutdown, paused,
       and startup.

FILES
       DBDIR/dhcpd.leases DBDIR/dhcpd.leases~

SEE ALSO
       dhcpd(8),   dhcp-options(5),   dhcp-eval(5),   dhcpd.conf(5),  RFC2132,
       RFC2131.

AUTHOR
       dhcpd(8)	is maintained by ISC.  Information about Internet Systems Con-
       sortium can be found at:	https://www.isc.org/

							       dhcpd.leases(5)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=dhcpd.leases&sektion=5&manpath=FreeBSD+14.3-RELEASE+and+Ports>

home | help