Routing Configuration Over DHCPv6

Currently the DHCPv6 protocol does not allow the provisioning of any routing-related information to hosts. A new proposal is addressing this shortcoming. The draft draft-ietf-mif-dhcpv6-route-option defines a mechanism for delivering routing information over the DHCPv6 protocol. This article explains core concepts and explains how to use the ISC DHCP software to deliver such information.

A bit of history

When the IPv6 protocol family was defined, it was decided that a new mechanism for discovering routers was necessary. Routers send Router Advertisement (RA) messages that contain their addresses and a list of routes that are reachable through them. These may contain additional information such as routes available directly on-link. This mechanism is an essential part of the Neighbor Discovery protocol. Currently, that is the only reasonable way of provisioning routing information to hosts. The other alternatives are usually avoided. Manually configuring each host in a network is very time consuming, error-prone and takes a lot of time, needing to be re-done in the event of any routing information changes. The last possible way of delivering routing information to hosts would be to participate in dynamic routing (like RIP, OSPF or BGP), but that is not feasible for hosts and problematic on several levels. Therefore nowadays most hosts are using RAs to configure their routing.

Problem definition

The RA-based approach works, but has several significant flaws:

1. RAs are multicast to all hosts. There is no way to differentiate this information on a per host basis. For example, assume that one of the departments in a corporate network requires access to a specific network (e.g. software engineering need to connect to a lab). Another example would be an access network where regular users are using one router, while premium users are allowed to also use a second router.
2. DHCPv6 requires RAs for proper operation. The DHCPv6 protocol assigns addresses but does not provide any information about routes. Imagine a separated network that does not have any routers. A DHCPv6 server assigns addresses to node A and node B. According to RFC3315, A and B cannot ping each other, even tough they have been assigned addresses from the same prefix. They do not have routing information, so they don't know how to reach each other.
3. Users who are experienced with IPv4 and DHCPv4 operation, when they begin migration to IPv6, have one very common question: "How do I specify routing information in DHCPv6?"
4. In mobile networks, a mobile node is expected to connect to a new network then wait for periodically announced RAs, then begin DHCPv6 if that is required. It may also request sending a RA immediately by sending Router Solicitation (RS) message, but that may not always work, due to restrictions placed on the routers regarding maximum number or RAs sent per specific period of time.

Solution

To solve those problems, several engineers involved in the Internet Engineering Task Force (IETF) decided to solve this problem. Draft-mif-dhcpv6-route-option defines a flexible way to provision routing information over DHCPv6. This draft is adopted by the Multiple Interfaces (MIF) Working Group and is currently going through Workgroup Last Call (WGLC) so it is expected to be approved and published soon. The proposed approach solves all of the aforementioned limitations. In particular, it allows configuration on a per host basis. It also allows configuration of the default route and availability of local on-link route(s). In a sense, it makes DHCPv6 complete, as it no longer requires RAs to operate.

There are several ways of delivering routing information to hosts.

1. The DHCPv6 server may inform hosts that a route X/Y is available via router Z. The lifetime of such route and its metric can be specified.
2. The DHCPv6 server may inform hosts that a route X/Y is available locally, directly on-link. The lifetime of such route and its metric can be specified.
3. In bandwidth constrained networks, a DHCPv6 server may inform clients that a default route is available via router X. This shorter option is discouraged unless there are significant bandwidth limitations.

Implementation

ISC provides several commercial quality open source software solutions, with ISC DHCP being one notable example. ISC DHCP is an implementation that supports both DHCPv4 and DHCPv6. It also offers a way to define custom options that are not supported directly. The following sections explain how to configure the existing ISC DHCP software to provision routing information to clients. The instructions were tested using the 4.2.3 release, but this approach should work on all currently supported versions from the 4.* family. Note that versions from the 3.x family do not support DHCPv6 and cannot be used for this purpose.

Server configuration

The following configuration file can be used to instruct a server to provision routing information to clients.

# Example server configuration for routing parameters
# as defined in draft-ietf-mif-dhcpv6-route-option-03

# This statement defines an option layout, not the values.
# NEXT_HOP option with RTPREFIX option included 
option dhcp6.next-hop-rt-prefix code 242 = { ip6-address, unsigned integer 16, 
   unsigned integer 16, unsigned integer 32, unsigned integer 8, unsigned integer 8, ip6-address };

# This statement configures actual values to be sent
# RTPREFIX option code = 243, RTPREFIX length = 22 
# lifetime = 9000 seconds 
# route 2001:db8:2::/64 
# metric 1 
option dhcp6.next-hop-rt-prefix 2001:db8:1::1 243 22 9000 64 1 2001:db8:2::;  

# Simplified mode (NEXT_HOP only, without RTPREFIX) for 
# bandwidth constrained networks. 
# Make sure that only simplified or full mode are uncommented, not both.
# Uncomment this if you want to send simplified default-route information 
#option dhcp6.next-hop code 242 = ip6-address; 
#option dhcp6.next-hop 2001:db8:1::1;  

# Uncomment this if you want to provision information about routes 
# available directly on-link.  

# RTPREFIX option layout definition 
option dhcp6.rtprefix code 243 = {unsigned integer 32, unsigned integer 8, unsigned integer 8, ip6-address };  

# RTPREFIX option values: 2001:db8:1:1234::/64 prefix
# with lifetime 3600 available on-link, metric 1
option dhcp6.rtprefix 3600 64 1 2001:db8:1:1234::;  

# This is the usual definition of subnet with range allocated
# for dynamic assignment. 
subnet6 2001:db8:1:15c::/64 {     

    # Range for clients     
    range6 2001:db8:1:15c::1:0 2001:db8:1:15c::1:ffff;      

    # standard options     
    option dhcp6.name-servers 2001:db8:1::1;     
    option dhcp6.domain-search "example.com"; 
}

Note that you must not mix full (NEXT_HOP with RTPREFIX option inside) and simplified (NEXT_HOP only) notation. Make sure that you have uncommented only one of them. Make sure that the client’s definition matches the server’s.

Tip: You may want to replace 2001:db8:2::/64 with ::/0 if you want to configure a default route using full notation.

Tip: When running this configuration, make sure that you use the -6 command-line flag (i.e., run the server in DHCPv6 mode, not in the default DHCPv4 mode) and that your machine running the server has an IPv6 address address assigned that belongs to subnet6.

Client configuration

The following configuration can be used by clients to retrieve routing information.

# Conf file for dhclient6
script "/path/to/your/client-script.sh";

# Uncomment this if you want to request only default route
#option dhcp6.option-next-hop code 242 = { ip6-address, encapsulate routing6 };

# Use this definition to provision default or any other specific route
# with addtional information (metric and lifetime).

# NEXT_HOP option with RTPREFIX option included
option dhcp6.next-hop-rtprefix code 242 = { ip6-address,
   unsigned integer 16, unsigned integer 16,
   unsigned integer 32,
   unsigned integer 8, unsigned integer 8, ip6-address };

# Simplified mode (NEXT_HOP only, without RTPREFIX)
# Uncomment this if you want to send simplified default-route information
# Make sure that only simplified or full mode are uncommented, not both.
#option dhcp6.next-hop code 242 = ip6-address ;
# RTPREFIX option
option dhcp6.rtprefix code 243 = {unsigned integer 32,
   unsigned integer 8, unsigned integer 8, ip6-address };

# This specifies list of options that client will request.
request dhcp6.name-servers, dhcp6.domain-search, dhcp6.rtprefix, dhcp6.next-hop-rtprefix;

The client will execute the specified script upon reception of this information. Several environment variables will be passed to that script. You should use their values to configure routing on your host. That varies between OSes, so please check the documentation for your system. For example, a client that receives routing information may pass the following variables:

new_dhcp6_next_hop_rtprefix='2001:db8:1::1 243 22 9000 64 1 2001:db8:2::'
new_dhcp6_rtprefix='3600 64 0 2001:db8:1:1234::'

Tip: If you are unsure about names of the variables, please consult the appropriate manual page. As a debugging assistance, you may also call the set command without arguments at the beginning of your script. It will print out all variables set.

Interoperability

Working drafts that are not yet published as RFCs do not typically have option values assigned. The presented examples use values 242 for NEXT_HOP and 243 for RTPREFIX option codes. Once the IETF approves this draft, IANA will assign actual option codes that are almost guaranteed to be different than those used in this example.

ISC is planning to provide direct support for NEXT_HOP and RTPREFIX options, without requiring users to resort to defining custom options. An exact schedule is not decided yet, as it depends on the standardization process of the draft in IETF.

The presented approach is non-proprietary and is interoperable with DHCP implementations from other vendors. It was tested to work with the development version of Dibbler, an open source DHCPv6 implementation.