✎ soc:2011:pcmattman:journal:week8

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Week 8 (July 11 to July 17) ======

==== Day 1 (July 11) ====

I began reworking the DHCPv6 code today to implement the necessary infrastructure for passing through the state machine. This will be quite similar to DHCPv4's state machine, with generic functions containing logic for transmission and receive that is the same across all states.

As part of these changes, I removed a lot of old testing solicit code and re-implemented it into the new infrastructure. This has worked well, with the DHCPv6 server sending ADVERTISE packets in response to the SOLICIT packet. I just have to set the right options to request an address (an IA_{NA|TA} option, for example).

At some point I will also need to modify the "settings" (gpxe/settings.h) code in gPXE to handle IPv6 addresses as well as IPv4 addresses. This will be useful for setting DNS nameservers and such, and I think I may also need to bring some of the settings changes into my stateless autoconfiguration code so that the IPv6 address of the network device is accessible.

I am now on a part time contract, so I have a bit more time in the day to work on gPXE code.

==== Day 2 (July 12) ====

I spent a fair bit of time today reading the RFCs for DHCPv6, trying to wrap my head around temporary and non-temporary addresses, and the IA_TA/IA_NA options in DHCPv6. This understanding is critical to being able to implement these features in gPXE properly.

I also implemented more of the SOLICIT state handling today. I can now send a request for an address, with the rapid commit option, and get an immediate reply from the DHCPv6 server. I managed to implement handling of this reply (generically, so there is no code duplication for a 4-way handshake transaction) but without the gpxe/settings.h changes I mentioned in yesterday's entry, I'm a bit stuck. So I'll be adding a few TODO comments in the code, and then continuing to implement the rest of the state machine. This way I can test each aspect of the DHCPv6 code and then sort out the settings changes later.

At some point I also need to install the ISC dhcpd, so I can test my DHCPv6 code with more than one server. At the moment I'm using WIDE's DHCPv6 server, which should work fine for this initial implementation phase.

==== Day 3 (July 13) ====

I managed to clean up some of the DHCPv6 option handling this evening, which makes reading through the code a bit nicer. This also came as a result of wanting to separate traversing the option list from actually using data in those options - another readability thing.

I'm fairly happy with how DHCPv6 is at with respect to rapid commits. It easily handles a transaction with a rapid commit and can get to the stage where I would set IP addresses and nameservers quite quickly. Tonight, though, I worked on the 4-way handshake (SOLICIT, ADVERTISE, REQUEST, REPLY). This has gone very well, with the code in place to send a REQUEST in response to an ADVERTISE - which means I'm now at the same stage here as with rapid commits (needing to set IP addresses and such). I do need to write a lot more code for the REPLY and ADVERTISE handling however - we need to confirm the response is actually for our own client ID, and that the server does not change between an advertisement and a reply. But everything is in place now to make that work.

Still haven't really looked into the gpxe/settings.h changes yet. Once DHCPv6 is cleaned up a bit and slightly more spec-friendly, I might have a look at this.

==== Day 4 (July 14) ====

Took some time to read the DHCPv6 specification again to make sure my progress is still "on the mark". I've made note of a few places where I may need to make some changes, which typically involve server/client verification and the correct response to unexpected packets.

So far so good though.

==== Day 5 (July 15) ====

I managed to implement checking of both the Client ID and Server ID in all packets that are received from a server this evening. This will keep gPXE from accepting DHCPv6-assigned addresses that don't actually belong to it, as well as keeping to the standard.

The initial of DHCPv6 is essentially complete at this stage, as a full transaction can be performed both with and without rapid commit support, as well as a standard Information Request (to retrieve only DNS servers, for example). Still lacking is the support for actually configuring gPXE with the outcome of a DHCPv6 session, but this will involve the previously mentioned settings.h changes. That will be the next thing I implement.

I'm also not sure about how to set up routing for DHCPv6 addresses yet. The RFC does not actually state that an IPv6 prefix or router information is provided as part of a standard address assignment, so it is impossible to globally route packets without a router advertisement. I'm half tempted to perform a router advertisement as the first stage in a DHCPv6 session, and store the resulting router and prefix for later use. This would require the router solicitation function to change a bit to return a bit more information, but I don't see that being a problem. The alternative is to try and manipulate existing IPv6 miniroutes or inject new routes hoping that it "just works".

One important note about completing this basic DHCPv6 support - aside from IPv6 fragmentation and proper handling of IPv6 extension headers, IPv6 support is now "functionally complete" in gPXE. Hurrah! :)
Trace: • oldundiproposal • winnt_srp • macbuild • journal • httpfsprobs • soc • dhcp_-_build_instructions • 2009 • ubuntu910 • winnt_iscsi_debug • sanboot • staging • srp • iscsibootprepfc5 • week2 • week7 • start • commandline • journal • 2010