<para>
Backend versions are specified in
a <replaceable>major.minor</replaceable> format. The minor
- number is increased when there are backward compatibile changes
+ number is increased when there are backward compatible changes
introduced. For example, the addition of a new index. It is
desirable, but not mandatory to apply such a change; you
can run on older database version if you want to. (Although, in
modem is different to the clients behind that modem.
</para></listitem>
<listitem><para>
- The clients have different behavior, e.g.a smart phone behaves
- differently to a lapttop.
+ The clients have different behavior, e.g. a smart phone behaves
+ differently to a laptop.
</para></listitem>
<listitem><para>
The clients require different values for some options, e.g. a docsis3.0
<command>result</command> indicates the outcome of the command. A value of 0
means success while any non-zero value designates an error. Currently 1 is
used as a generic error, but additional error codes may be added in the
- future.<command>text</command> field typically appears when result is
+ future. <command>text</command> field typically appears when result is
non-zero and contains a description of the error encountered, but it may
also appear for successful results. That's command specific.
<command>arguments</command> is a map of additional data values returned by
<para>
<emphasis>shutdown</emphasis> command instructs the server to initiate
- its shutdown procedure. It is the equivalent of sending a SIGTERM singal
+ its shutdown procedure. It is the equivalent of sending a SIGTERM signal
to the process. This command does not take any arguments. An example
command may look like this:
<screen>
directly. The following command may be used to extract this
information. The binary <userinput>path</userinput> may be found
in the install directory or in the <filename>.libs</filename>
- subdirectory in the source treee. For example
+ subdirectory in the source tree. For example
<filename>kea/src/bin/d2/.libs/kea-dhcp-ddns</filename>.
<screen>
strings <userinput>path</userinput>/kea-dhcp-ddns | sed -n 's/;;;; //p'
</simpara>
</listitem>
<listitem>
- <simpara><command>conf name</command>: The confguration file name
+ <simpara><command>conf name</command>: The configuration file name
used to start the server, minus all preceding path and file extension.
For example, given a pathname of "/usr/local/etc/kea/myconf.txt", the
portion used would be "myconf".
lease address. The zone name should follow the appropriate
standards: for example, to to support the IPv4 subnet 172.16.1,
the name should be. "1.16.172.in-addr.arpa.". Similarly,
- to support an IPv6 subent of 2001:db8:1, the name should be
+ to support an IPv6 subnet of 2001:db8:1, the name should be
"1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa."
Whatever the name, it must be unique within the catalog.
</simpara>
directly. The following command may be used to extract this
information. The binary <userinput>path</userinput> may be found
in the install directory or in the <filename>.libs</filename>
- subdirectory in the source treee. For example
+ subdirectory in the source tree. For example
<filename>kea/src/bin/dhcp4/.libs/kea-dhcp4</filename>.
<screen>
</simpara>
</listitem>
<listitem>
- <simpara><command>conf name</command>: The confguration file name
+ <simpara><command>conf name</command>: The configuration file name
used to start the server, minus all preceding path and file extension.
For example, given a pathname of "/usr/local/etc/kea/myconf.txt", the
portion used would be "myconf".
default value <userinput>raw</userinput> is used.
</para>
- <para>Using UDP sockets automatically disables the reception of brodcast
+ <para>Using UDP sockets automatically disables the reception of broadcast
packets from directly connected clients. This effectively means that the
UDP sockets can be used for relayed traffic only. When using the raw sockets,
both the traffic from the directly connected clients and the relayed traffic
will be handled. Caution should be taken when configuring the server to open
multiple raw sockets on the interface with several IPv4 addresses assigned.
- If the directly connected client sends the message to the brodcast address
+ If the directly connected client sends the message to the broadcast address
all sockets on this link will receive this message and multiple responses
will be sent to the client. Hence, the configuration with multiple IPv4
addresses assigned to the interface should not be used when the directly
mentioned in the <xref linkend="dhcp4-interface-configuration"/>. From
the administrator's perspective it is often desired to be able to
configure the system's firewall to filter out the unwanted traffic, and
- the use of UDP sockets faciliates it. However, the administrator must
+ the use of UDP sockets facilitates it. However, the administrator must
also be aware of the implications related to filtering certain types
of traffic as it may impair the DHCP server's operation.
</para>
<title>Unspecified parameters for DHCPv4 option configuration</title>
<para>In many cases it is not required to specify all parameters for
an option configuration and the default values may be used. However, it is
- important to understand the implications of not specifing some of them
+ important to understand the implications of not specifying some of them
as it may result in configuration errors. The list below explains
the behavior of the server when a particular parameter is not explicitly
specified:
</para>
<para>
- This example shows a configuration using an automatcially generated
+ This example shows a configuration using an automatically generated
"VENDOR_CLASS_" class. The Administrator of the network has
decided that addresses from range 192.0.2.10 to 192.0.2.20 are
going to be managed by the Dhcp4 server and only clients belonging to the
database for this client, using the client identification information as a
search key.</simpara></listitem>
<listitem><simpara>Some configurations use static reservations for the IP
- addreses and other configuration information. The server's administrator
+ addresses and other configuration information. The server's administrator
uses client identification information to create these static assignments.
</simpara></listitem>
<listitem><simpara>In the dual stack networks there is often a need to
database and will hand out the existing lease rather than allocate
a new one. Each lease in the lease database is associated with the
'client identifier' and/or 'chaddr'. The server will first use the
- 'client identifer' (if present) to search the lease. If the lease is
+ 'client identifier' (if present) to search the lease. If the lease is
found, the server will treat this lease as belonging to the client
even if the current 'chaddr' and the 'chaddr' associated with
the lease do not match. This facilitates the scenario when the network card
new reservation has been made for the client for the address being currently
in use by another client. We call this situation a "conflict". The conflicts
get resolved automatically over time as described in the subsequent sections.
- Once conflict is resolved,the client will keep receiving the reserved
+ Once conflict is resolved, the client will keep receiving the reserved
configuration when it renews.</para>
<para>Another example when the host reservations are applicable is when a host
has to be identified by its hardware/MAC address. There is an optional
<command>reservations</command> array in the <command>Subnet4</command>
element. Each element in that array is a structure, that holds information
- about reservrations for a single host. In particular, such a structure has
- to have an indentifer that uniquely identifies a host. In DHCPv4 context, such an
+ about reservations for a single host. In particular, such a structure has
+ to have an identifier that uniquely identifies a host. In DHCPv4 context, such an
identifier is a hardware or MAC address. In most cases, also an address
will be specified. It is possible to specify a hostname. Additional
capabilities are planned.</para>
]
</screen>
The first entry reserves the 192.0.2.202 address for the client that uses
- MAC adress of 1a:1b:1c:1d:1e:1f. The second entry reserves the address
+ MAC address of 1a:1b:1c:1d:1e:1f. The second entry reserves the address
192.0.2.100 and the hostname of alice-laptop for client using MAC
address 0a:0b:0c:0d:0e:0f. Note that if you plan to do DNS updates, it
is strongly recommended for the hostnames to be unique.
also must not be reserved for another client. Second, when renewing a lease,
additional check must be performed whether the address being renewed is not
reserved for another client. Finally, when a host renews an address, the server
- has to check whether there's a reservation for this host, so the exisiting
+ has to check whether there's a reservation for this host, so the existing
(dynamically allocated) address should be revoked and the reserved one be
used instead.
</para>
that it is expected to hand out to the DHCPv4 clients. It is
assumed that the server is authoritative and has complete jurisdiction
over those addresses. However, due to various reasons, such as
- misconfiguration or a faulty client implemetation that retains its
+ misconfiguration or a faulty client implementation that retains its
address beyond the valid lifetime, there may be devices connected that use
those addresses without the server's approval or knowledge.</para>
hook returns (both global and subnet specific variants).</para>
<para>Once the probation time elapses, the declined lease is recovered
- using the standard expired lease reclaimation procedure, with several
+ using the standard expired lease reclamation procedure, with several
additional steps. In particular, both declined-addresses statistics
(global and subnet specific) are decreased. At the same time,
reclaimed-declined-addresses statistics (again in two variants, global and
<entry>declined-addresses</entry>
<entry>integer</entry>
<entry>
- This statistic shows the number of IPv4 adresses that are
+ This statistic shows the number of IPv4 addresses that are
currently declined. This statistic counts the number of leases
currently unavailable. Once a lease is recovered, this
statistic will be decreased. Ideally, this statistic should be
<entry>subnet[id].declined-addresses</entry>
<entry>integer</entry>
<entry>
- This statistic shows the number of IPv4 adresses that are
+ This statistic shows the number of IPv4 addresses that are
currently declined in a given subnet. This statistic counts the
number of leases currently unavailable. Once a lease is
recovered, this statistic will be decreased. Ideally, this
<entry>reclaimed-declined-addresses</entry>
<entry>integer</entry>
<entry>
- This statistic shows the number of IPv4 adresses that were
+ This statistic shows the number of IPv4 addresses that were
declined, but have now been recovered. Unlike
declined-addresses, this statistic never decreases. It can be used
as a long term indicator of how many actual valid Declines were
<entry>subnet[id].reclaimed-declined-addresses</entry>
<entry>integer</entry>
<entry>
- This statistic shows the number of IPv4 adresses that were
+ This statistic shows the number of IPv4 addresses that were
declined, but have now been recovered. Unlike
declined-addresses, this statistic never decreases. It can be used
as a long term indicator of how many actual valid Declines were
directly. The following command may be used to extract this
information. The binary <userinput>path</userinput> may be found
in the install directory or in the <filename>.libs</filename>
- subdirectory in the source treee. For example
+ subdirectory in the source tree. For example
<filename>kea/src/bin/dhcp6/.libs/kea-dhcp6</filename>.
<screen>
</simpara>
</listitem>
<listitem>
- <simpara><command>conf name</command>: The confguration file name
+ <simpara><command>conf name</command>: The configuration file name
used to start the server, minus all preceding path and file extension.
For example, given a pathname of "/usr/local/etc/kea/myconf.txt", the
portion used would be "myconf".
<title>Unspecified parameters for DHCPv6 option configuration</title>
<para>In many cases it is not required to specify all parameters for
an option configuration and the default values can be used. However, it is
- important to understand the implications of not specifing some of them
+ important to understand the implications of not specifying some of them
as it may result in configuration errors. The list below explains
the behavior of the server when a particular parameter is not explicitly
specified:
<para>There are certain conditions that must be met for the option to be
included. First, the server must not provide the option by itself. In
other words, if both relay and server provide an option, the server always
- takes precedence. Second, the option must be RSOO-enabled. IANA mantains a
+ takes precedence. Second, the option must be RSOO-enabled. IANA maintains a
list of RSOO-enabled options <ulink url="http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#options-relay-supplied">here</ulink>.
However, there may be cases when system administrators want to echo other
options. Kea can be instructed to treat other options as RSOO-enabled.
In certain cases it is useful to differentiate between different types
of clients and treat them accordingly. It is envisaged that client
classification will be used for changing the behavior of almost any part of
- the DHCP message processing, including the assignement of leases from different
- pools, the assigment of different options (or different values of the same
- options) etc. In the current release of the sofware however, there are
+ the DHCP message processing, including the assignment of leases from different
+ pools, the assignment of different options (or different values of the same
+ options) etc. In the current release of the software however, there are
only two mechanisms that take advantage of client classification:
- subnet selection and assignment of differnet options.
+ subnet selection and assignment of different options.
</para>
<para>
</para>
<para>
- This example shows a configuration using an automatcially generated
+ This example shows a configuration using an automatically generated
"VENDOR_CLASS_" class. The Administrator of the network has
decided that addresses from range 2001:db8:1::1 to 2001:db8:1::ffff are
going to be managed by the Dhcp6 server and only clients belonging to the
<command>reservations</command> array in the
<command>Subnet6</command> structure. Each element in that array
is a structure, that holds information about a single host. In
- particular, such a structure has to have an indentifer that
+ particular, such a structure has to have an identifier that
uniquely identifies a host. In DHCPv6 context, such an identifier
is a hardware (MAC) address or a DUID. Also, either one or more
addresses or prefixes should be specified. It is possible to
It is not allowed to define multiple host definitions with the same hardware
address in a single subnet. It is a valid configuration, if such definitions
are specified in different subnets, though. The reservation for a given host
- should include only one identifier, either DUID or hwardware address. Defining
+ should include only one identifier, either DUID or hardware address. Defining
both for the same host is considered a configuration error, but as of 0.9.1
beta, it is not rejected.
</para>
<section id="reservation6-conflict">
<title>Conflicts in DHCPv6 reservations</title>
<para>As reservations and lease information are stored in different places,
- conflicts may arrise. Consider the following series of events. The server
+ conflicts may arise. Consider the following series of events. The server
has configured the dynamic pool of addresses from the range of 2001:db8::10
to 2001:db8::20. Host A requests an address and gets 2001:db8::10. Now the
system administrator decides to reserve an address for host B. He decides
</para>
<para>
- The hexadecimal representation of the DUID-EN created accoring to
+ The hexadecimal representation of the DUID-EN created according to
the configuration above is:
<screen>
00:02:00:00:09:BF:87:AB:EF:7A:5B:B5:45
<section id="mac-in-dhcpv6">
<title>MAC/Hardware addresses in DHCPv6</title>
- <para>MAC/hardware addesses are available in DHCPv4 messages
+ <para>MAC/hardware addresses are available in DHCPv4 messages
from the clients and administrators
frequently use that information to perform certain tasks, like per host
- configuration, address reserveration for specific MAC addresses and other.
+ configuration, address reservation for specific MAC addresses and other.
Unfortunately, the DHCPv6 protocol does not provide any completely reliable way
to retrieve that information. To mitigate that issue a number of mechanisms
have been implemented in Kea that attempt to gather that information. Each
<simpara><command>duid</command> - DHCPv6 uses DUID identifiers instead of
MAC addresses. There are currently four DUID types defined, with two of them
(DUID-LLT, which is the default one and DUID-LL) convey MAC address information.
- Although RFC3315 forbids it, it is possible to parse those DUIDs and extract
+ Although RFC 3315 forbids it, it is possible to parse those DUIDs and extract
necessary information from them. This method is not completely reliable, as
clients may use other DUID types, namely DUID-EN or DUID-UUID.
</simpara>
</listitem>
<listitem>
- <simpara><command>ipv6-link-local</command> - Another possible aquisition
+ <simpara><command>ipv6-link-local</command> - Another possible acquisition
method comes from the source IPv6 address. In typical usage, clients are
sending their packets from IPv6 link-local addresses. There's a good chance
that those addresses are based on EUI-64, which contains MAC address. This
method is not completely reliable, as clients may use other link-local address
- types. In particular, privacy extensions, defined in RFC4941, do not use
+ types. In particular, privacy extensions, defined in RFC 4941, do not use
MAC addresses. Also note that successful extraction requires that the
address's u-bit must be set to 1 and its g-bit set to 0, indicating that it
is an interface identifier as per
addresses that it is expected to hand out to the DHCPv6 clients.
It is assumed that the server is authoritative and has complete
jurisdiction over those addresses. However, due to various
- reasons, such as misconfiguration or a faulty client implenetation
+ reasons, such as misconfiguration or a faulty client implementation
that retains its address beyond the valid lifetime, there may be
devices connected that use those addresses without the server's
approval or knowledge.</para>
returns (both global and subnet specific variants).</para>
<para>Once the probation time elapses, the declined lease is recovered
- using the standard expired lease reclaimation procedure, with several
+ using the standard expired lease reclamation procedure, with several
additional steps. In particular, both declined-addresses statistics
(global and subnet specific) are decreased. At the same time,
reclaimed-declined-addresses statistics (again in two variants, global and
<entry>
Number of ADVERTISE packets received. Advertise packets are sent
by the server and the server is never expected to receive them. A non-zero
- value of this statistic indicates an error ocurring in the network.
+ value of this statistic indicates an error occurring in the network.
One likely cause would be a misbehaving relay agent that incorrectly
forwards ADVERTISE messages towards the server, rather back to the
clients.
<entry>declined-addresses</entry>
<entry>integer</entry>
<entry>
- This statistic shows the number of IPv6 adresses that are
+ This statistic shows the number of IPv6 addresses that are
currently declined. This statistic counts the number of leases
currently unavailable. Once a lease is recovered, this
statistic will be decreased. Ideally, this statistic should be
<entry>subnet[id].declined-addresses</entry>
<entry>integer</entry>
<entry>
- This statistic shows the number of IPv6 adresses that are
+ This statistic shows the number of IPv6 addresses that are
currently declined in a given subnet. This statistic counts the
number of leases currently unavailable. Once a lease is
recovered, this statistic will be decreased. Ideally, this
<entry>reclaimed-declined-addresses</entry>
<entry>integer</entry>
<entry>
- This statistic shows the number of IPv6 adresses that were
+ This statistic shows the number of IPv6 addresses that were
declined, but have now been recovered. Unlike
declined-addresses, this statistic never decreases. It can be used
as a long term indicator of how many actual valid Declines were
<entry>subnet[id].reclaimed-declined-addresses</entry>
<entry>integer</entry>
<entry>
- This statistic shows the number of IPv6 adresses that were
+ This statistic shows the number of IPv6 addresses that were
declined, but have now been recovered. Unlike
declined-addresses, this statistic never decreases. It can be used
as a long term indicator of how many actual valid Declines were
<section>
<title>Supported Platforms</title>
<para>
- Kea is officially supported on RedHat Enterprise Linux,
+ Kea is officially supported on Red Hat Enterprise Linux,
CentOS, Fedora and FreeBSD systems. It is also likely to work on many
other platforms: builds have been tested on (in no particular order)
Debian GNU/Linux 6 and unstable, Ubuntu 9.10, NetBSD 5,
</para>
<para>Kea's servers create PID files upon startup. These files are used
- by keactrl to deteremine whether or not a given server is running. If
+ by keactrl to determine whether or not a given server is running. If
one or more servers are running when the start command is issued, the
- output will look similiar to the following:
+ output will look similar to the following:
<screen>
<userinput>$ keactrl start</userinput>
INFO/keactrl: kea-dhcp4 appears to be running, see: PID 10918, PID file: /usr/local/var/kea/kea.kea-dhcp4.pid.
the cycles.
</para>
- <para>According to the <command>reclamim-timer-wait-time</command> the
+ <para>According to the <command>reclaim-timer-wait-time</command> the
server keeps fixed intervals of 5 seconds between the end of one cycle
and the start of the next cycle. This guarantees the presence of
5s long periods during which the server remains responsive to DHCP
<section id="kea-lfc-overview">
<title>Overview</title>
<para><command>kea-lfc</command> is a service process that removes
- redundant infomation from the files used to provide persistent storage
+ redundant information from the files used to provide persistent storage
for the memfile data base backend. This service is written to run as a
stand alone process.
</para>
When <command>kea-lfc</command> starts this
is the result of any previous run of <command>kea-lfc</command>.
When <command>kea-lfc</command> finishes it is the result of this run.
- If <command>kea-lfc</command> is interrupted before compelting
+ If <command>kea-lfc</command> is interrupted before completing,
this file may not exist.
</simpara></listitem>
</listitem>
<listitem>
<simpara><command>kea-dhcp4.bad-packets</command> - this is the
- logger used by the DHCPv4 server deamon for logging inbound client
+ logger used by the DHCPv4 server daemon for logging inbound client
packets that were dropped or to which the server responded with a
- DHCPNAK. The allows adminstrators to configure a separate log
+ DHCPNAK. The allows administrators to configure a separate log
output that contains only packet drop and reject entries.</simpara>
</listitem>
<listitem>
</listitem>
<listitem>
<simpara><command>kea-dhcp4.dhcp4</command> - this is the logger
- by the DHCPv4 server deamon to log basic operations.</simpara>
+ by the DHCPv4 server daemon to log basic operations.</simpara>
</listitem>
<listitem>
<simpara><command>kea-dhcp4.dhcpsrv</command> - this is a base
<listitem>
<simpara><command>kea-dhcp4.hosts</command> - this logger is used
within the libdhcpsrv and it logs messages related to the management
- of the DHCPv4 host reservations, i.e. retrieval of the resevations
+ of the DHCPv4 host reservations, i.e. retrieval of the reservations
and adding new reservations.</simpara>
</listitem>
<listitem>
</listitem>
<listitem>
<simpara><command>kea-dhcp6.bad-packets</command> - this is the
- logger used by the DHCPv6 server deamon for logging inbound client
+ logger used by the DHCPv6 server daemon for logging inbound client
packets that were dropped.</simpara>
</listitem>
<listitem>
</listitem>
<listitem>
<simpara><command>kea-dhcp6.dhcp6</command> - this is the logger
- used DHCPv6 server deamon to log basic operations.</simpara>
+ used DHCPv6 server daemon to log basic operations.</simpara>
</listitem>
<listitem>
<simpara><command>kea-dhcp6.dhcpsrv</command> - this is a base
<listitem>
<simpara><command>kea-dhcp6.hosts</command> - this logger is used
within the libdhcpsrv and it logs messages related to the management
- of the DHCPv6 host reservations, i.e. retrieval of the resevations
+ of the DHCPv6 host reservations, i.e. retrieval of the reservations
and adding new reservations.</simpara>
</listitem>
<listitem>
</listitem>
<listitem>
<simpara><command>kea-dhcp-ddns</command> - this is the root logger for
- the kea-dhcp-ddns deamon. All components used by this deamon inherit
+ the kea-dhcp-ddns daemon. All components used by this daemon inherit
the settings from this logger if there is no specialized logger
provided.</simpara>
</listitem>
<listitem>
<simpara><command>kea-dhcp-ddns.dhcpddns</command> - this is the logger
- used by the kea-dhcp-ddns deamon for logging configuration and global
+ used by the kea-dhcp-ddns daemon for logging configuration and global
event information. This logger does not specify logging settings
- for libraries used by the deamon.</simpara>
+ for libraries used by the daemon.</simpara>
</listitem>
<listitem>
<simpara><command>kea-dhcp-ddns.dhcp-to-d2</command> - this is the logger
- used by the kea-dhcp-ddns deamon for logging information about events
- dealing with receving messages from the DHCP servers and adding them
+ used by the kea-dhcp-ddns daemon for logging information about events
+ dealing with receiving messages from the DHCP servers and adding them
to the queue for processing.</simpara>
</listitem>
<listitem>
<simpara><command>kea-dhcp-ddns.d2-to-dns</command> - this is the logger
- used by the kea-dhcp-ddns deamon for logging information about events
+ used by the kea-dhcp-ddns daemon for logging information about events
dealing with sending and receiving messages with the DNS servers.
</simpara>
</listitem>
</para>
<para>
The following environment variables can be used to control the
- behavio of logging during startup:
+ behavior of logging during startup:
</para>
<variablelist>
<listitem>
<para>
- If the server has been started sucessfully, test that it is
+ If the server has been started successfully, test that it is
responding to DHCP queries and that the client
receives a configuration from the server; for example, use
the <ulink url="http://www.isc.org/downloads/DHCP/">ISC DHCP client</ulink>.
<title>Running Kea servers directly</title>
<para>Kea servers can be started directly (without a need to use
<command>keactrl</command>). To start DHCPv4 server run the following
- commmand:
+ command:
<screen># <userinput>kea-dhcp4 -c /path/to/your/kea4/config/file.json</userinput></screen>
And, to start the DHCPv6 server run the following command:
<screen># <userinput>kea-dhcp6 -c /path/to/your/kea6/config/file.json</userinput></screen>
projects / thirdparty / kea.git / commitdiff
