Requesting help appending relay agent option in v6

Petrin, Benjamin b.petrin at WPI.EDU
Wed Sep 2 20:13:30 UTC 2009


I was able to get this option added by moving it into the dhcpv6_universe. This obviously isn't a permanent solution but we at least now have a working proof of concept for here around the office. It seems that store_options6() doesn't yet handle anything outside of dhcpv6_universe...

If anyone has similar need for the hardware address of the client as an option I can provide the patch, just let me know. We still have a few outstanding issues (for instance, the relay agent doesn't yet have the entry in the neighbor discovery table when it forwards the packet, I've been pinging the client as a quick and dirty hack for testing the code) but I'm working on finding a more elegant solution to that. 

Benjamin Petrin
________________________________________
From: dhcp-workers-bounces at lists.isc.org [dhcp-workers-bounces at lists.isc.org] On Behalf Of Petrin, Benjamin [b.petrin at WPI.EDU]
Sent: Tuesday, September 01, 2009 1:25 PM
To: dhcp-workers at lists.isc.org
Subject: RE: Requesting help appending relay agent option in v6

It's been some time now but I'm back in school and back on a project I had started last year: trying to modify the v6 relay agent to append the mac address of the client as an option to the packet going up to the server (necessary for how we handle registering machines on the network around here).

I had mentioned in the old email below that I had proof of concept code working and performing the source address to hardware address lookup from the neighbor discovery table. I now have this integrated with the relay agent and running without problem, happily performing this translation. I'm still, however, having a bit of trouble getting this into an option. So now in "process_up6" of relay/dhcrelay I'm trying to do something like the following:

        char lladr[6];
        lookup_lladr(piaddr(packet->client_addr),lladr, 6); /*the function I wrote to do the lookup */

        /*at this point, lladr has the hardware address */

        if (!save_option_buffer(&dhcpv6_universe, opts,
                                NULL, (unsigned char *) lladr,
                                6,
                                ISC6_RELAY_OBSERVED_MAC, 0)) {
                log_error("Can't save link layer address.");
                option_state_dereference(&opts, MDL);
                return;
        }

       /* Add the relay-msg carrying the packet. */
       ......

save_option_buffer is returning 0 (good) but inspecting the forwarded packet I don't see the option added. I'm sure there is more I don't understand about how to append this option but stepping through the code as of now I am at a loss.

Any suggestions would be greatly appreciated.

Benjamin Petrin

________________________________________
From: dhcp-workers-bounces at lists.isc.org [dhcp-workers-bounces at lists.isc.org] On Behalf Of David W. Hankins [David_Hankins at isc.org]
Sent: Wednesday, April 01, 2009 1:32 PM
To: dhcp-workers at lists.isc.org
Subject: Re: Requesting help appending relay agent option in v6

On Wed, Apr 01, 2009 at 12:05:49PM -0400, Petrin, Benjamin wrote:
> I'm attempting to make changes to the relay agent for v6 to add an option to the packets being processed upwards (client to server) that contains the hardware address of the client. I have developed code that will retrieve the hardware address for the client from the relay agent's neighbor discovery table based on the IPv6 source address (thanks David Hankins for the hint there).

Excellent.

> So I now need to append this as an option to the packet. I'm looking at "process_up6" in /relay/dhcrelay.c and I can see where the interface-id and relay-msg are added to the packet. I'm looking for a bit of assistance on how I can go about adding another option without breaking anything...I'm getting a little lost in the "save_option_buffer" function being called in common/options.c as well as "prepare_option_buffer". Is there someone that wouldn't mind explaining a bit how these work and go about affecting the outward bound packet?

There are several DHCP authors at ISC now, and it wasn't me who wrote
the DHCPv6 relay bits, so I'm going to have to also pick up sourcecode
to refresh my memory.

As a starting place, you need an option code to use; you can use ISC's
Vendor Specific Information Option space.  We used a couple option
codes recently for default-router and prefix related work, so use the
next code after that;

Index: DHCP/common/tables.c
diff -u DHCP/common/tables.c:1.73 DHCP/common/tables.c:1.73.150.1
--- DHCP/common/tables.c:1.73   Thu Jan 24 02:43:04 2008
+++ DHCP/common/tables.c        Fri Mar 20 00:28:08 2009
@@ -559,7 +559,9 @@
 struct universe isc6_universe;
 static struct option isc6_options[] = {
        { "media", "t",                         &isc6_universe,     1, 1 },
-       { "update-assist", "X",                 &isc6_universe,     2, 1 },
+       { "update-assist", "X",                 &isc6_universe,     2, 1 },
+       { "router", "6TXo",                     &isc6_universe,     3, 1 },
+       { "prefix", "6BTT",                     &isc6_universe,     4, 1 },
        { NULL, NULL, NULL, 0, 0 }
 };

So use code 5 for now.  You probably want an "X" format;

        { "relay-observed-mac", "X",            &isc6_universe,     5, 1 },

Put a #define for the code in includes/dhcp6.h (before the 'OFFSET'
defines but after the 'DUID' enumeration defines);

  #define ISC6_RELAY_OBSERVED_MAC 5


The save option buffer and so forth calls are the way ISC DHCP works
with DHCP option state.  We create an 'option cache', an empty bucket
into which we put option code and content buffer pairs.  At packet
creation time, we interrogate the cache while constructing the packet.

This is so we can do complete processing around a received packet, and
delay the question of "which values to send" until the last moment.

I'm going to have to pick up the sourcecode to see how to get VSIO
options into the relay's output.  It probably isn't very
straightforward.  I'm back from IETF anyway, so I should be able to
help out soon.

--
David W. Hankins        "If you don't do it right the first time,
Software Engineer                    you'll just have to do it again."
Internet Systems Consortium, Inc.               -- Jack T. Hankins
_______________________________________________
dhcp-workers mailing list
dhcp-workers at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-workers



More information about the dhcp-workers mailing list