Dynamic Host Configuration Protocol

“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

Dynamic Host Configuration Protocol

The need for DHCP

Any protocol is essentially a software that runs on a specific computer and

manages all the "talking" with other computers in the "protocol language". In
order for the same software to run on different machines there is a need to
initialize the protocol with parameters specific to that machine and to the
local network before starting proper operation. Initialization can be done
during booting (if the protocol is embedded in the operating system) or it can
be triggered by a specific application (if the protocol is embedded into the
application).

Take for example the TCP/IP protocol stack: first of all, the IP protocol needs
to know the IP address of the computer. Moreover, it needs to know the
network subnet-mask, IP addresses of the default router, the printer, the DNS
and perhaps some other servers etc.

Those parameters can be configured manually and locally for each and every
computer. Using a mechanism like that introduces some problems:

1. A lot of manual work is required by the network administrator, being time

consuming and error prone.
2. Keeping the parameters up-to-date is not a one-time effort. The amount of work
increases with the changes in the net (e.g portable computers that change locations
frequently introduce a lot of daily work for network administrators).
3. A change in a parameter common to all the computers in a subnet
(e.g: local router's address) forces changes in each computer on the net.
4. Some systems may not have a permanent storage device (e.g. hard disk) to store
the configuration parameters - in which case no local configuration can be
considered.
5. In cases of shortage in IP addresses and a network that is changing frequently it
can be a waist to give a computer (that may be out of the network for a while) a
permanent address. A better approach will be to use common pool of addresses by
a set of computers. Manual configuration give no easy way of doing so.

All those reasons lead to the need in an automated mechanism for TCP/IP
protocols' configuration and DHCP is the currently most advanced
mechanism for doing so.

DHCP Goals

Compatibility

The DHCP protocol must be compatible with existing interface and protocols;
For example it should be compatible with all the types of clients, each one
can have a different configuration of communication parameters.

BRBRAITT : Nov-2006 2
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

As mentioned in "Protocol introduction", the DHCP protocol should have

compatibility with the BOOTP protocol which was used before.

Local control

Although the DHCP protocol is an external mechanism for allocating a web

address and communication parameters, the administrator of the client must
have the capability to control these parameters.

Communication parameters preserving:

The DHCP server has to give a specific client the same communication
parameters in as many sequential requests as possible, so if a client was
disconnected from the web and requests its address/communication
parameters again, it would receive the same communication parameters as
before. (if nothing has changed since the disconnection).
The same is for the DHCP server, which should have the capability to give
the same client the same communication parameters even if it was
disconnected from the web.

Unique clients

A main goal of the DHCP protocol is to give each client its unique address. A
situation in which two or more clients are allocated with the same web
address must not occur in any circumstances, to prevent a situation of client
send a message to the wrong client.

Automatic Configuration

Usually, a single client should have to be configured automatically by the

DHCP server and not manually by the administrator of that client. A situation
in which the configuration of the communication parameters is done
manually by the client's administrator should occur seldom. But when it
happens, the DHCP server must be compatible with the manual configuration
as mentioned before.

Saving hardware

There should not be a DHCP server for each and every link interface. There
should be a wide use of relay-agents to transmit a DHCP messages. If less
DHCP servers are used, it's more financialy agreeable because we'll use the
relay-agents which are simpler. The hardware saving will lead to more
economically worthwhile network and will save money as mentioned in
"protocol introduction".

Historical background

At first, most TCP/IP networks were relatively small and static. Manual IP
address management techniques were sufficient for them. Each station kept
its own IP address somewhere in its secondary storage. Once the address had

BRBRAITT : Nov-2006 3
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

to be changed, it required manual administrator action, usually at the machine

console, and in most cases involved a reboot.

Soon afterwards, as more complex networks were established, as more and

more underlying network hardware was used for TCP/IP communication
networks and as cheap client workstations without secondary storage came in
use, a need for central administration of the hardware to P addresses bindings
became obvious. A special protocol (RARP) for such bindings was designed.
It allowed a machine on a network segment to learn its own IP address and
then to begin normal TCP/IP operation.

Another protocol, BOOTP, was also developed to allow diskless stations

retrieve all the TCP/IP configuration parameters and other operating system
data, needed to start functioning normally after a startup. It allowed
configuration over broader networks as it was not limited to a single segment.
For that purpose BOOTP defined the concept of a BOOTP relay agent which
specified how BOOTP traffic is forwarded between multiple segments.

BOOTP was designed to be easily extended by the BOOTP extension

mechanism. This mechanism uses the last field in the frame for more
(vendor) specific data and message options.

The next attempt to extend BOOTP provided the Dynamic Host

Configuration Protocol, DHCP. DHCP wad designed to be backward
compatible with BOOTP in order to support BOOTP clients and BOOTP
relay agents, yet there are two primary differences between DHCP and
BOOTP:

• DHCP defines a mechanism through which a client can be assigned a

network address for a finite lease, allowing for a serial reuse the same
network address by different clients.
• DHCP provides a mechanism for a client to request and acquire all the
IP configuration parameters that it needs in order to operate, and only
them.

DHCP comes with a predefined set of DHCP options, which it inherits from
the BOOTP vendor extensions mechanism, and it is open for further
extension, inheriting the openness from BOOTP.

Main differences between BOOTP AND DHCP:

The DHCP is an extension of the previous BOOTP protocol, thus it must be

compatible with BOOTP messages, but there are some differences between
BOOTP and DHCP.

One difference is that DHCP is designed to allocate a web address to a client

temporarily so the client can disconnect allowing another client to get this
web address, or renew the lease of the web address, a capability which the
BOOTP protocol does not have.

BRBRAITT : Nov-2006 4
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

Another difference is that the DHCP can configure a client with all the IP
parameters that the client needs in order to establish communication. One
BOOTP transfer only some of these parameters.
Moreover, the BOOTP protocol had a field named 'vendor extentions', to
specify the requested parameters and other options, which were replaced with
the field 'options' in the DHCP protocol.

In addition, the BOOTP protocol had a field named "chaddr" in order to

specify the address of the client which has requested the communication
parameters. In DHCP protocol, there is the field "client identifier". This field
can have the physical address of the client as in "chaddr" of the BOOTP
protocol, or it can have another identifier like DNS name, or another types.
New types of identifier can be registered in IANA.

DHCP is currently the most advanced host configuration mechanism for

TCP/IP, although it still has its problems, giving researchers things to work
on, for an even better configuration protocol in the future.

Protocol Introduction

General

The Dynamic Host Configuration Protocol (DHCP) provides configuration

parameters to Internet hosts in a client-server model. DHCP server hosts
allocate network addresses and deliver configuration parameters to other
(client) hosts.

DHCP consists of two components: a protocol for delivering host-specific

configuration parameters from a server to a host and a mechanism for
allocation of network addresses to hosts.

IP Address Allocation

DHCP supports three mechanisms for IP address allocation.

• Automatic allocation -- in which a permanent IP address is assigned to

the client.
• Dynamic allocation -- in which the address is assigned for a limited
period of time (a "lease").
• Manual allocation -- in which the address is assigned manually by the
network administrator.

Configuration Parameters Delivery

The client sends a message to request configuration parameters and the server
responds with a message carrying the desired parameters back to the client.

BRBRAITT : Nov-2006 5
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

BOOTP Compatibility

The format of DHCP messages is based on the format of BOOTP messages

due to the following reasons:

• From the client's point of view, is an extension of the BOOTP

mechanism. This behavior allows existing BOOTP clients to
interoperate with DHCP servers without requiring any change to the
clients' initialization software.
• DHCP supports the BOOTP relay agent behavior.

Use of Relay Agents

DHCP does not require a server on each subnet. To allow for scale and
economy, DHCP can work across routers or through the intervention of
BOOTP relay agents. A relay agent listens to DHCP messages and forwards
them on (and onto other network segments). This eliminates the necessity of
having a DHCP server on each physical network.

Allocation of network addresses

DHCP supports three mechanisms for IP address allocation. The DHCP

server can use any one or more of the of these mechanisms:

1. Automatic allocation: The DHCP server assigns a permanent IP

address to a client without any manual interference. Automatic
allocation is best suited for in cases where hosts are permanently
connected to a network and the network does not suffer from an
address shortage.
2. Manual allocation:The client's IP address is assigned manually by the
network administrator. The DHCP server simply retrieves it from its
storage and delivers it to the client. Manual allocation is best suited
for giving IP addresses to servers of any kind. As servers are the ones
to be addressed, rather than to initiate a conversation, their location
should be permanent and known in the network. Manual allocation
would guarantee that (although a clever use of Automatic allocation
can accomplish that too).
3. Dynamic allocation: The DHCP server assigns a temporary IP address
to a client without any manual interference.

Dynamic allocation is the most interesting method of the three, because it

involves not only the assigning of a network address but also reclaiming and
reusing of the same address by another client. Therefore, using Dynamic
allocation allows for an efficient managing of a pool of network addresses
and is particularly useful in cases where:

BRBRAITT : Nov-2006 6
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

• There is a limited amount of network addresses on the net.

• The network has computers which temporarily connect and
disconnect to it (e.g. portable computers) and so the network is
changing frequently.

The basic mechanism for the dynamic allocation of network addresses is

simple: the client requests the use of an address for a limited period of time
(which is called a lease). The DHCP server allocates an address for the client,
marks it as 'used' and notifies the client about the address and the lease time
approved.
The client, in his turn, can:

• Extend its lease with subsequent requests.

• Ask for a permanent assignment by asking for an infinite lease.
• Release the address back to the server before the lease expires, in case
it doesn't need it.

Renewing and acquiring addresses

The client holds two times in its memory ? time1, and time2.
The first time is the time in which the client starts to ask its server for
renewing the lease of its address ? RENEWING state in the states diagram of
the protocol.
The second time is the time in which the client starts to ask other servers for
address ? REBINDING state in the states diagram of the DHCP protocol.

When the first time arrives, the client sends the DHCPREQUEST message to
the server with unique ID to this request. If the renew is approved, the server
will send an answer in DHCPACK message with this ID. Then the client
returns to normal functioning. The new time1 will be the sum of the time in
the server's answer and the time which has passed from the start of the
request to the answer.

If no answer has arrived until time2 has passed, the client will enter the
REBINDING state in the states diagram of the DHCP protocol, and will send
a multicast message to all the servers available to acquire new address.

These times can be changed by servers in the 'option' field, and have default
values. The default of time1 is half of the lease time of the current address,
and the default of time2 is 0.875x(lease time).

In both cases ? time1 and time2, if the client has not got an answer from the
DHCP servers, it should wait half of the time which is left before sending
DHCPREQUEST again. The shortest waiting time is one minute.

If the client has got its previous address, it continues to work normally. If the
client didn't get its previous address but got a new one, he should continue
working, but not with the current web parameters, and must inform the users

BRBRAITT : Nov-2006 7
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

about this. If the client didn't manage to get an address at all, it should stop its
work and go back to INIT state in the states diagram of the DHCP protocol.

Configuration Parameters Delivery

The DHCP server is designed to supply DHCP clients with the configuration
parameters defined in the Host Requirements RFCs (1122 and 1123). Most of
those parameters are related to the TCP/IP protocol stack but DHCP allows
the configuration of non-related parameters too.

The server provides a permanent storage of network parameters for network

clients. The DHCP storage model is a set of key-value pairs for each client,
where the key is some unique identifier and the value contains the
configuration parameters for the client. In other words, the storage model is a
per-host list of entries of the form:

key = value

The client addresses the server with a request message to retrieve its
configuration parameters. The server answer with a response message
carrying the configuration parameters in the (later discussed) options field.

Not all clients require initialization of all possible parameters. Two techniques
are used to reduce the number of parameters delivered from the server to the
client:

1. Most of the parameters have defaults defined in the Host

Requirements RFCs (1122 and 1123). If the client receives no
parameters from the server that override the defaults, a client uses
those default values.
2. A client and server may negotiate for the delivery of only those
parameters required by the client. In a case like that the client includes
the parameter request list option in the requested message and fills it
with the list of parameters it needs.

Message Format

As mentioned earlier, the format of the DHCP messages is based on the

format of BOOTP messages in order to keep compatible with BOOTP relay
agents and BOOTP clients.

Here is the DHCP message format. The numbers in parentheses indicate the
size of each Field in Bytes.

BRBRAITT : Nov-2006 8
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

Description of Fields in a DHCP message

Field Bytes Description

Message op code / message type.
op 1
1 = BOOTREQUEST, 2 = BOOTREPLY
htype 1 Hardware address type (e.g., '1' = 10Mb Ethernet)
hlen 1 Hardware address length (e.g. '6' for 10Mb Ethernet)
Client sets to zero, optionally used by relay agents when booting
hops 1
via a relay agent.
Transaction ID.
xid 4 A random number chosen by the client, used by the client and
server to associate the request message with its response.
Seconds passed since client began the request process.
secs 2
Filled in by client.
flags 2 Flags
Client IP address.
Filled in by client if it knows its IP address (from previous
ciaddr 4
requests or from manual configurations) and can respond to ARP
requests.
yiaddr 4 'your' (client) IP address. Server's response to client.
Server IP address. Address of sending server or of the next server
siaddr 4
to use in the next bootstrap process step.
giaddr 4 Relay agent IP address, used in booting via a relay agent.
chaddr 16 Client hardware address.
sname 64 Optional server host name. Null terminated string.
Boot file name.
file 128 Null terminated string; "generic" name or null in request, fully
qualified directory-path name in reply.
Field to hold the optional parameters.
options variable
(See next section).

BRBRAITT : Nov-2006 9
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

The 'options' Field in a DHCP message

Apart from the small amount of the Fields imported from the BOOTP frame
format there came a need for a lot more Fields, some of them changing from
one message to another, others from one subnet to another etc.

That need came first after defining the BOOTP protocol which led to the
BOOTP extension mechanism, where the last Field in the frame format, the
'vendor extensions' filed was of variable length and could contain the extra
information. DHCP improved this mechanism, changing the Field name to
'options' and adding more options.

One way to categorize those options would be to split them into two groups:

• Configuration parameters.
• Message control information.

All options begin with a tag octet, which uniquely identifies the option. The
next octet is the option length specifier, its value does not include the two
Bytes specifying the tag and length. The length octet is followed by length
Bytes of data.

All these options/vendor extensions are defined in RFC 2132, where they are
split to the following groups:

• RFC 1497 Vendor Extensions.

• IP Layer Parameters per Host.
• IP Layer Parameters per Interface.
• Link Layer Parameters per Interface.
• TCP Parameters.
• Application and Service Parameters.
• DHCP Extensions.

Some important DHCP options:

Message Type (a DHCP control):

Specifies the type of the DHCP message in order to be more specific than
the originally BOOTP Field 'op'. Different message types are used at
different stages of the client/server interaction.
Appears in every DHCP message (therefore the 'options' Field is never
empty):

BRBRAITT : Nov-2006 10
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

Renewal Time Value (a DHCP control):

Specifies the time interval from address assignment until the client
attempts to contact the server that originally issued the client's network
address before the lease expire.

Parameter Request List (a DHCP control):

A list of valid DHCP option codes. Used by a DHCP client to request

values for specified configuration parameters.
Subnet Mask (a Configuration parameter):
Specifies the client's subnet mask.
DNS Option (a Configuration parameter):
Specifies a list of DNS name servers available to the client.

Message Format in IPv6

Every message in DHCP protocol of IPv6 has a constant length header and
variable length data. This data is located in the "options" Field, and composed
from Bytes, in network byte format (least significant byte first.)

This is the format of a message which sent from client directly to the server:

Field Bytes Description

This is the type of the message chosen from the 11 types of
msg-type 1 direct messages from client to server (an exact list in
"Message Types Summary").
transaction-
3 The ID for this message transport.
id
options variable The options for this message.

This is the format of a message from relay-agent to another relay-agent or a

server:

BRBRAITT : Nov-2006 11
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

Field Bytes Description

msg-type 1 The code of the message, RELAY-FORW or RELAY-REPL.
Counts the relay-agents which the message has passed until
hop-count 1
now.
link- Used by the server to identify the link of the client in RELAY-
12
address FORW message or in RELAY-REPL message.
peer- The address of the relay-agent or the client from which the
12
address message was received ? the current hop.
Options for the message. Here the message has to have "Relay
options variable
Message option" among the other options.

The options are in this format:

BRBRAITT : Nov-2006 12
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

Field Bytes Description

option- The number of option according to "types
2
code of options".
option-len 2 The length of the option-data in bytes.
the value in "option-len" in
option-data The data of the options.
bytes

Client/Server Model

The client and the server negotiate in a series of messages in order for the
client to get the parameters it needs.

The following diagram shows the messages exchanged between the DHCP
client and servers when allocating a new network address. Next is a detailed
explanation of all the various messages and a description of the
communication steps.

This process can involve more than one server but only one server is selected
by the client. In the figure, the selected server is marked 'selected' and the
other, 'not selected' server stands for all the possible not selected servers.

Description of the communication steps

1. The client broadcasts a DHCPDISCOVER.

2. Each server may responds with a DHCPOFFER message.
3. The client receives one or more DHCPOFFER messages from one or
more servers and chooses one server from which to request
configuration parameters.

The client broadcasts a DHCPREQUEST message.

4. Those servers not selected by the DHCPREQUEST message use the

message as notification that the client has declined that server's offer.

BRBRAITT : Nov-2006 13
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

The server selected in the DHCPREQUEST message commits the

responds with a DHCPACK message containing the configuration
parameters for the requesting client.

5. The client receives the DHCPACK message with configuration

parameters. At this point, the client is configured.

If the client receives a DHCPNAK message, the client restarts the

configuration process.

6. The client may choose to relinquish its lease on a network address by

sending a DHCPRELEASE message to the server (e.g. on shutdown).
7. The server receives the DHCPRELEASE message and marks the
lease as free.

Variations on the timeline diagram

There are two main variations on the presented client/server interaction
scenario:
1. Reuse of a previously allocated network address:
If a client remembers (in its cache) and wishes to reuse a previously
allocated network address, a client may choose to omit some of the
steps taken in case of a new allocation.
In the first DHCPREQUEST the client includes its network address
in the 'requested IP address' option. The server that has the knowledge
of the client's configuration respond with a DHCPACK message and
from then on the diagram continues from step (5).
2. Obtaining parameters with externally configured network address:
If a client has obtained a network address through some other means
(e.g., manual configuration), it may use a DHCPINFORM request
message to obtain other local configuration parameters. Servers
receiving a DHCPINFORM message construct a DHCPACK
message with any local configuration parameters appropriate for the
client without allocating a new address.

Message Types

Message Use

DHCPDISCOVER Client broadcast to locate available servers.

DHCPOFFER Server to client in response to DHCPDISCOVER with offer

of configuration parameters.

BRBRAITT : Nov-2006 14
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

DHCPREQUEST Client message to servers either (a) requesting offered

parameters from one server and implicitly declining offers
from all others, (b) confirming correctness of previously
allocated address after, e.g., system reboot, or (c) extending
the lease on a particular network address.

DHCPACK Server to client with configuration parameters, including

committed network address.

DHCPNAK Server to client indicating client's notion of network address is

incorrect (e.g., client has moved to new subnet) or client's
lease as expired

DHCPDECLINE Client to server indicating network address is already in use.

DHCPRELEASE Client to server relinquishing network address and canceling

remaining lease.

DHCPINFORM Client to server, asking only for local configuration

parameters; client already has externally configured network
address.

Message types in IPv6

Message Use

SOLICIT This message is sent by a node to discover new DHCP

servers.

BRBRAITT : Nov-2006 15
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

ADVERTISE This message is sent by the DHCP server in response to a

"SOLICIT" message. It means that this DHCP server is
available to serve the client.

REQUEST A request of an address and communication parameters after a

node has found a DHCP server.

CONFIRM A multicast message to all DHCP servers which are available,

to confirm, that its address is still appropriate to its link.

RENEW A request to renew address lifetime or updating

communication parameters. The message is sent to a specific
DHCP server which has sent its address/communication
parameters beforehand.

REBIND A multicast message to all the servers available with the

request to renew address or updating its communication
parameter. This message is sent after a "RENEW" request
didn't get any response from the node?s DHCP server.

REPLY A message that is sent to a node by a DHCP server.

Address/communication parameters are sent in response to a
"SOLICIT", "REQUEST", "RENEW" or "REBIND"
messages from a node. Additionally it is used to confirm or
reject an address in response to a "CONFIRM" message, or it
simply used as an ack message in response to a "RELEASE"
or "DECLINE" message from a node.

RELEASE A message from a node to the DHCP server which granted it

an address. It is sent when the node no longer needs that
adress. This message is mean to let the DHCP server know
that this address is free to use by other nodes.

BRBRAITT : Nov-2006 16
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

DECLINE A message to the DHCP server which means that a node

declines the address which is already taken, and the node
requests another address. It can happen when a node discovers
that an address which the DHCP server has gaven it is used by
another node in the link.

RECONFIGURE A message sent by the DHCP server when it wants to update a

node's communication parameters. The node response should
be a "RENEW" message back to the DHCP server.

INFORMATION- This message is sent to a DHCP server when a node wants to

REQUEST get communication parameters without an address.

RELAY-FORW A message which is sent from relay-agent to a DHCP server

or another relay-agent, and encapsulates the innitial message
from a node to the DHCP server.

RELAY-REPL A message which is sent from DHCP server or another relay-

agent to a certain relay-agent, and encapsulates the innitial
message from a DHCP server to the node.

Security in DHCP

Security is a significant subject in when concidering DHCP, this is because

the main goal is to get communication parameters/IP address from an external
source. This can give an opportunity do damage the host from outside of the
system.

There numerous threats to a host which using DHCP. For example:

Deploying fake DHCP servers that will always deny service. Another way is
by sending incorrect communication parameters and wrong DHCP server
information either because of flawed server, or deliberatelly.

These threats require authentication of the DHCP server or/and the

communication parameters to ensure that we are dealing with real DHCP
server which sends valid parameters.

In order to achieve higher safety, the following two rules must be obeyed:

BRBRAITT : Nov-2006 17
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

1. The protocol cannot be changed. (i.e. its stucrute, msg types etc. must
remain intact.)
2. Interact with the DHCP server as little as possible ? minimize the
number of stages of the communication with the DHCP server.

Main way to authenticate a DHCP message is to include an authentication

field in the "option" field of the DHCP message.
This is the format of DHCP client/server message with "authentication
option?:

Description of Fields in a DHCP message

Code Bytes Description

op 1 The code of an authentication message is 90.
Length 1 The length of the information data.
The name of the protocol used for authentication (there are
Protocol 1
number of techniques).
The name of the algorithm used by the protocol in the
Algorithm 1
"protocol" field.
RDM stands for "Replay Detection Method" ? the method
RDM 4
used for replay detection.
Replay This is a sequence of authentication. If the RDM field is 0x00,
8
Detection the sequence must be a monotonic increasing counter.

Security in IPv6

In addition to the method of adding "options", like in IPv4, there is also use
of the IPsec mechanisms for communication between relay-agents or relay-

BRBRAITT : Nov-2006 18
“DATA NETWORKS” FOR JTOs PH-II – Dynamic Host Configuration Protocol

agent - server in IPv6.

IPSec is mechanism of security on the IP level. It provides services such as
reply detection, access control etc.

The servers and relay-agents are configured manually. Each relay-agent or

server has to hold a list of pairs of servers and relay-agents to know which
one will get the message. Servers and relay agents can accept messages only
from DHCP sources which are on the list in their configuration.

In addition to this tool, one can use also the general security tools of IPv6 for
DHCP security. There are many sources to these tools in the web, and a
partial list can be found in This Link.

BRBRAITT : Nov-2006 19