DHCPv4 Over DHCPv6 (RFC7341) in ISC DHCP 4.3.4
  • 04 Sep 2018
  • 5 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

DHCPv4 Over DHCPv6 (RFC7341) in ISC DHCP 4.3.4

  • Dark
    Light
  • PDF

Article Summary

General

In ISC DHCP 4.3.4 we have added experimental support for DHCPv4 Over DHCPv6 as described in RFC7341. This work is designed to aid the transition of the Internet from IPv4 to IPv6. It provides a mechanism for a "v4 island" to get information from a remote DHCPv4 server across a set of IPv6 networks. 

To achieve this, a DHCPv4 client will send its request to a DHCPv6 client which then encapsulates it within a DHCPv6 request and sends the result to a DHCPv6 server (potentially via one or a set of DHCPv6 relays). When the DHCPv6 server receives the request it extracts the DHCPv4 request and passes it on to a DHCPv4 server. For the reply from the DHCPv4 server the chain is reversed. A simple diagram would look like this:

DHCPv4 client -> DHCPv6 client -> IPv6 network -> DHCPv6 Server -> DHCPv4 server

In order for this to work all four of the functional pieces must co-operate.

  1. The DHCPv4 client must know to connect to the DHCPv6 client

  2. The DHCPv6 client must be prepared to receive requests from the DHCPv4 client and must request a DHCP 4o6 address option to find a participating server.

  3. The DHCPv6 server must supply the DHCP 4o6 address option to the DHCPv6 client and be prepared to receive requests from the client and forward them to the DHCPv4 server.

  4. The DHCPv4 server must be prepared to receive the DHCPv4 request and additional information from the DHCPv6 server and pass the request and the additional information back to the DHCPv6 server.

It is an implementation detail as to whether the two clients and two servers are combined into a single client or server or if they are split into two separate co-operating processes. 

In ISC DHCP they are split into two processes and use a pair of UDP sockets for communication. The RFC defines the protocol between the client(s) and the server(s) and our client pair and server pair should be able to inter-operate with others that adhere to the standard. 

We would not expect that one of our clients would inter-operate with another vendor's client or one of our servers would inter-operate with another vendor's server.

OK - [ISC DHCPv4 client -> ISC DHCPv6 client]  --> [other vendor DHCP 4o6 server]
Not OK - [ISC DHCPv4 client -> other vendor DHCPv6 client]  --> [other vendor DHCP 4o6 server]
Not OK - [ISC DHCPv4 client -> ISC DHCPv6 client] --> [ISC DHCPv6 server -> other vendor DHCPv4 server]

Compilation

In order to minimize effects on the existing ISC DHCP code, all of the additional code for DHCP 4o6 has been isolated and will not be compiled-in by default. In order to include the code you will need to add the --enable-dhcpv4o6 option to your configuration command and then build the code. 

Please note:
The DHCP 4o6 feature requires the DHCPv6 feature and is not compatible with delayed-ack.

Below is a sample build of ISC DHCP that enables this feature.

./configure --enable-dhcpv4o6
make

This will produce the normal set of programs: client, relay, and server.  

Running

Whilst the DHCP 4o6 code is now compiled into the programs it will not be run by default. In order to use this new feature you will also need to tell the client pair and/or server pair that they are operating the 4o6 protocol and how they are to communicate with each other.

This is achieved by using the command line option -4o6 to either a client or server. As the function requires a pair of clients or servers you will need to start the programs twice - once for v4 and once for v6. The two processes use a pair of UDP ports for communication. They are started with a port value that indicates two ports to use port and port+1 . Both processes of a pair must be started with the same value for port .  For example:

./dhclient -d -4 -4o6 6767 -lf leases4 -pf pid4 eth1  
./dhclient -d -6 -4o6 6767 -lf leases6 -pf pid6 eth1  

In the example above (starting the client pair) we are using the ports 6767 and 6768. We have also specified the lease file and the pid file in order to ensure that they are different for the two processes. Either client can be stopped and restarted independently, though if the DHCPv6 client is stopped the DHCPv4 client will be unable to communicate with its server. This example also includes the -d command line argument which will leave the processes in the foreground, this may be useful when testing.

./dhcpd -f -d -6 -4o6 6769 -cf ./dhcpd.conf6 -lf ./leases6 -pf .pid6 eth1  
./dhcpd -f -d -4 -4o6 6769 -cf ./dhcpd.conf4 -lf ./leases4 -pf .pid4  

Above where we're starting the server pair we use a different port pair (6769 and 6770) than the clients (although that isn't necessary as they are almost certainly on different machines). Again we specify separate configuration, lease and pid files. Both lease files must be created before starting the servers (but can be empty); there is no change to this requirement when running a 4o6 pair.

When using 4o6, the DHCPv4 server does not include an interface name when starting.
This is because its communication path with its clients is via the DHCPv6 server.

Configuration

The clients do not require any special configuration files.

The configuration file for the DHCPv6 server has only one addition, the DHCP 4o6 server address. A simple configuration file is:

#DHCPv6 conf  
authoritative;default-lease-time 3600;  
max-lease-time 7200;  
option dhcp6.dhcp4-o-dhcp6-server 2001:db8:1:1::1; 
subnet6 2001:db8:1:1::/64 {  
   range6 2001:db8:1:1::1:0/112;  
}  

The configuration for the DHCPv4 server requires a mechanism for it determine which network it should select when choosing an address for the client. 

As the DHCPv4 message has been relayed through DHCPv6 it will generally lack the information a server would normally use to determine the network (GIADDR, IPv4 Address on the receiving interface, etc). To solve this the configuration includes the IPv6 address that is associated with the proper subnet.  The server then chooses the appropriate subnet (or shared network) based on the IPv6 address associated with the message and chooses an IPv4 address from the IPv4 pool. A simple configuration would be:

#DHCPv4 conf  
authoritative;  
default-lease-time 3600;  
max-lease-time 7200;  
shared-network "test" {  
    subnet6 2001:db8:1:1::/64 {}  
    subnet 10.10.10.0 netmask 255.255.255.0 {  
            range 10.10.10.100 10.10.10.199;  
    }  
}