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 pa-
       rameter,	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)

NAME | DESCRIPTION | FORMAT | COMMON STATEMENTS FOR LEASE DECLARATIONS | THE DHCPv4 LEASE DECLARATION | THE DHCPv6 LEASE (IA) DECLARATION | THE FAILOVER PEER STATE DECLARATION | FILES | SEE ALSO | AUTHOR

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

home | help