Commit 9fdc1f5a authored by Marcin Siodelski's avatar Marcin Siodelski
Browse files

[2765] Updated Developer's guide with the section about raw sockets use.

parent fe717f9c
...@@ -66,6 +66,7 @@ ...@@ -66,6 +66,7 @@
* - @subpage libdhcpIntro * - @subpage libdhcpIntro
* - @subpage libdhcpRelay * - @subpage libdhcpRelay
* - @subpage libdhcpIfaceMgr * - @subpage libdhcpIfaceMgr
* - @subpage libdhcpPktFilter
* - @subpage libdhcpsrv * - @subpage libdhcpsrv
* - @subpage leasemgr * - @subpage leasemgr
* - @subpage cfgmgr * - @subpage cfgmgr
......
// Copyright (C) 2012 Internet Systems Consortium, Inc. ("ISC") // Copyright (C) 2012-2013 Internet Systems Consortium, Inc. ("ISC")
// //
// Permission to use, copy, modify, and/or distribute this software for any // Permission to use, copy, modify, and/or distribute this software for any
// purpose with or without fee is hereby granted, provided that the above // purpose with or without fee is hereby granted, provided that the above
...@@ -137,4 +137,52 @@ Another useful methods are dedicated to transmission ...@@ -137,4 +137,52 @@ Another useful methods are dedicated to transmission
Note that receive4() and receive6() methods may return NULL, e.g. Note that receive4() and receive6() methods may return NULL, e.g.
when timeout is reached or if dhcp daemon receives a signal. when timeout is reached or if dhcp daemon receives a signal.
@section libdhcpPktFilter Switchable Packet Filter objects used by Interface Manager
The well known problem of DHCPv4 implementation is that it must be able to
provision devices which don't have an IPv4 address yet (the IPv4 address is
one of the configuration parameters provided by DHCP server to a client).
One way to communicate with such a device is to send server's response to
a broadcast address. An obvious drawback of this approach is that the server's
response will be received and processed by all clients in the particular
network. Therefore, the preferred approach is that the server unicasts its
response to a new address being assigned for the client. This client will
identify itself as a target of this message by checking chaddr and/or
Client Identifier value. In the same time, the other clients in the network
will not receive the unicast message. The major problem that arises with this
approach is that the client without an IP address doesn't respond to ARP
messages. As a result, server's response will not be sent over IP/UDP
socket because the system kernel will fail to resolve client's link-layer
address.
Kea supports the use of raw sockets to create a complete Data-link/IP/UDP/DHCPv4
stack. By creating each layer of the outgoing packet, the Kea logic has full
control over the frame contents and it may bypass the use of ARP to inject the
link layer address into the frame. The raw socket is bound to a specific interface,
not to the IP address/UDP port. Therefore, the system kernel doesn't have
means to verify that Kea is listening to the DHCP traffic on the specific address
and port. This has two major implications:
- It is possible to run another DHCPv4 sever instance which will bind socket to the
same address and port.
- An attempt to send a unicast message to the DHCPv4 server will result in ICMP
"Port Unreachable" message being sent by the kernel (which is unaware that the
DHCPv4 service is actually running).
In order to overcome these issues, the isc::dhcp::PktFilterLPF opens a
regular IP/UDP socket which coexists with the raw socket. The socket is referred
to as "fallback socket" in the Kea code. All packets received through this socket
are discarded.
In general, the use of datagram sockets is preferred over raw sockets.
For convenience, the switchable Packet Filter objects are used to manage
sockets for different purposes. These objects implement the socket opening
operation and sending/receiving messages over this socket. For example:
the isc::dhcp::PktFilterLPF object opens a raw socket.
The isc::dhcp::PktFilterLPF::send and isc::dhcp::PktFilterLPF::receive
methods encode/decode full data-link/IP/UDP/DHCPv4 stack. The
isc::dhcp::PktFilterInet supports sending and receiving messages over
the regular IP/UDP socket. The isc::dhcp::PktFilterInet should be used in all
cases when an application using the libdhcp++ doesn't require sending
DHCP messages to a device which doesn't have an address yet.
*/ */
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment