BIND 9.20 Brings Streamlined Core, Some New Features
Today, ISC is proud to release BIND 9.20.0, our newest stable branch.
Read postCurrently 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.
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.
The RA-based approach works, but has several significant flaws:
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.
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.
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.
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.
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.
What's New from ISC