Week 6 (June 27 to July 3)

Today was mostly spent finalising the last couple of changes after Guo-Fu's review. I also spent a while upgrading my router's distribution version; I'm hoping I'll be able to get some neat IPv6 features that weren't in the older packages I was using. I still need to work on getting the ISC DHCPv6 server installed and tested, but I'm also wrapping my head around the actual architecture of DHCPv4 in gPXE before I go too deep into implementing it on my network and in gPXE.

In this evening's meeting we managed to sort out a plan for the week that should see testing of my code soon. We will also be working on flash6, hopefully getting a few test images up there for everyone to test.

Today I am reading through DHCPv4's implementation mainly. It's quite a complicated protocol, and the code is not by any means simple, but the architecture is something I'd like to emulate for DHCPv6. Just understanding the construction and transmission of a packet is a good place to start, and then I can work on moving through the full state machine. The state machine is what makes DHCPv6 more complicated to implement than, say, router solicitations. Each transaction needs to be tracked, and just to make things exciting, some DHCP servers allow “Rapid Commit” which cuts out half the state machine (but only if it's supported and enabled!).

I expect DHCPv6 will be the main focus for quite a while now. I intentionally left room in the project plan for things like DHCPv6 to take longer than expected, thankfully. IPv6 fragmentation and proper option handling in IPv6 packets are the “Big Two” to complete after DHCPv6 - and then lots of testing and bug fixing!

I was busy with real-world commitments this evening.

Finally figured out how dhcp.c actually transmits DISCOVER packets on the network to kick off the state machine. This is the final piece of the puzzle of understanding the architecture of DHCPv4 in gPXE, which means I can now emulate it in DHCPv6. The RFC has proven to be very straightforward as well and I feel confident about implementing this protocol now. I prefer it over trying to learn a protocol as I'm implementing it, as that often ends up creating code that is truly ugly in the end. Looking back at my first TCP implementation proves this :).

I was once again busy with real-world commitments today. I did however manage to do some more reading and I have determined that, architecturally, it would be simpler to implement new support code for IPv6 instead of attempting to copy or modify the existing DHCPv4 implementation. This is because the fundamental protocol is completely different - rather than a new protocol tacked onto BOOTP (DHCPv4), it's been done “right” from the very beginning. Packet manipulation and working with options is not necessarily something that needs a full C file worth of code (dhcppkt.c).

Working this weekend on gPXE to make up for lost time.

I managed to finally TX a DHCP6 solicit and get an ADVERTISE response. This is a good start, even if the code to transmit the solicit is totally hacked together. It's much simpler to implement compared to DHCPv4 as well. I don't know if it'll get more complex as I support more options, but I'm happy with progress so far!

I plan on using DHCP6 rapid commits so that on supported DHCP6 servers/configurations we can minimise the DHCP6 network traffic and speed up the boot process.

Experimentation with this has shown that I can actually get DNS nameservers and such without needing to perform a full transaction; I should just be able to send an Information-Request packet and get a response containing the information. This makes sense, because there is no need to “commit” an address to the DHCP6 server. I intend to use this if SLAAC gets a usable globally routable address to try and get IPv6-based nameservers from the network.

I have yet to explore the network boot properties (ie, filenames and servers) of DHCP6.