Building

Is RFC 6939 Support Finally Here – Checking the Implementation of the “Client Link Layer Address Option” in DHCPv6

One of the main DHCPv6 enhancements – fyi: we have already discussed DHCPv6 in some other posts – many practitioners have been waiting for quite some time now, is full support of RFC 6939 (Client Link-Layer Address Option in DHCPv6) by network devices (acting as relays) and DHCPv6 servers. RFC 6939 support would allow a number of things which large organizations use in their DHCPv4 based networks, incl.

  • reservations (assigning a kind-of fixed DHCP address based on the MAC address of a system which in turn allows for “centralized administration of somewhat static addresses”).
  • correlation of IPv4 and IPv6 addresses of a given host identified by its MAC address.
  • (some type) of security enforcement based on the MAC address of a host gathered in the course of a DHCP exchange (see for example slide #29 of this presentation of the IPv6 deployment at CERN, btw: slide #9 might be helpful when discussing IPv6 transition plans with your CIO. or not).

So far it seemed very few components support RFC 6939. When Tim Martin mentioned at Cisco Live that Cisco devices running IOS XE support it by default, we decided go to the lab ;-).

Here’s the write-up Antonios provided:

While DHCPv4 Specification provides a way to specify the client link-layer address in the DHCPv4 message header, this is not the case regarding DHCPv6, which does not define a way to communicate the client link-layer address to the DHCPv6 server when the latter is not connected to the same network link with the DHCPv6 client. This can cause a number of problems, either for security/tracking purposes or operational ones when an administrator needs to correlate DHCPv4 and DHCPv6 assignments.

To this end, in May of 2013 RFC 6939 was standardized, which introduces an optional mechanism to allow first-hop DHCPv6 relay agents to provide the client’s link-layer address in the DHCPv6 messages being forwarded to the server. The option introduced for this mechanism is the so called “Client Link-Layer Address” one, whose value is 79.

Given that ISC DHCP supports the “Client Link-Layer Address” since version 4.3 as well as that, as mentioned above, Cisco supports out-of-the-box in certain devices RFC 6939 when used as DHCPv6 Relays, we decided to give it a try.

For our tests we used a Cisco 4321, IOS XE Software, Version 03.14.00.S  acting as a Relay, while our server was an ISC DHCP version 4.3.1. Our client was an Ubuntu 14.04, which could make things more difficult since it uses DUID Type 4 (UUID-Based DHCPv6 Unique Identifier) and not DUID based on Link-layer Address Plus Time (Option 1) which includes, among else, the Link-Layer address.

The configuration of the interface that we used was the following:

interface GigabitEthernet0/0/0
 ip address 192.168.0.2 255.255.255.0
 media-type rj45
 negotiation auto
 ipv6 address FE80:2::2 link-local
 ipv6 address 2001:DB8:DEAD:BEAF::1/64
 ipv6 enable
 ipv6 nd prefix 2001:DB8:DEAD:BEAF::/64 infinite infinite no-autoconfig
 ipv6 nd managed-config-flag
 ipv6 nd ra interval 10
 ipv6 dhcp relay destination 2001:DB8:C001:CAFE::1

 

In the above configuration, we should notice:

a) that the “management flag” in router advertisements is set (of course).
b) the dhcp relay configuration.

At first it was really easy to confirm that the Cisco acting as relay has indeed implemented RFC 6939 by observing the following Wireshark screenshot (Client Link-Layer Address Option is highlighted):

DHCPv6Relay2

So, we only have to use this information properly at our ISC DHCP server, which is not the case out of the box. And this was actually the tricky part.
To make a long story short, and thanks to the help provided at the dhcp-users mailing list by Espen Tallaksen, we need to include the following configuration in our dhcpd.conf file:

log (info, concat (“Lease for “, binary-to-ascii(16,16, “:”, substring(suffix(option dhcp6.ia-na, 24),0,16)), ” lease to “,v6relay(1, (binary-to-ascii(16, 8, “:”, option dhcp6.client-linklayer-addr)))));

In the above configuration, the v6relay does the job. I had tried before the rest of the configuration without v6relay, but the dhcp6.client-linklayer-addr could not be parsed.

So, using the above configuration we get the following information in our corresponding log file (in our case /var/log/dhcpd):

2015-02-04T09:52:43.245402+02:00 localhost dhcpd: Relay-forward message from 2001:db8:c001:cafe::2 port 547, link address 2001:db8:dead:beaf::1, peer address fe80::e611:5bff:feXX:YYZZ
2015-02-04T09:52:43.245437+02:00 localhost dhcpd: Lease for 2001:db8:dead:beaf:0:0:0:254 lease to 0:1:e4:11:5b:XX:YY:ZZ
2015-02-04T09:52:43.245873+02:00 localhost dhcpd: Lease for 2001:db8:dead:beaf:0:0:0:254 lease to 0:1:e4:11:5b:XX:YY:ZZ
2015-02-04T09:52:43.245965+02:00 localhost dhcpd: Reply NA: address 2001:db8:dead:beaf::254 to client with duid 00:04:22:c3:41:fd:61:e6:87:a0:b0:0b:d7:b4:3c:d4:af:a7 iaid = 1529472053 valid for 600 seconds
2015-02-04T09:52:43.246093+02:00 localhost dhcpd: Sending Relay-reply to 2001:db8:c001:cafe::2 port 547

As you can see, among else, we get the following:

Lease for 2001:db8:dead:beaf:0:0:0:254 lease to 0:1:e4:11:5b:XX:YY:ZZ

where e4:11:5b:XX:YY:ZZ is the MAC address of the client and 0:1 is the type of the link-layer address as described in RFC 0826.

Of course, we also get the date/time of the lease, its duration, the IPv6 addresses of the relay, etc.

Now, if we want to go one step further, we can use the RFC 6939 option to make a reservation via the DHCPv6 server by using the (client’s) link-layer address and not the DUID (which is the “standard” DHCPv6 way). In such a case, we can use v6relopt and include the following configuration inside the defined subnet6:

        host specialclient {
                host-identifier v6relopt 1 dhcp6.client-linklayer-addr 0:1:e4:11:5b:XX:YY:ZZ;
                fixed-address6 2001:db8:dead:beaf::127;
        }

By using this, the client with MAC address e4:11:5b:XX:YY:ZZ will get the IPv6 address 2001:db8:dead:beaf::127 which we could successfully test and hence confirm.
So, enterprise admins have at least some choices to correlate IPv6 and link-layer addresses as well as to make reservations based on them :).

We consider growing RFC 6939 support as a quite important element in DHCPv6 based IPv6 deployments.
Hope you enjoyed reading, have a good one

Antonios & Enno

 

Leave a Reply

Your email address will not be published. Required fields are marked *