Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
soc:2011:pcmattman:journal:week6 [2011/06/28 02:58] pcmattman days 1 and 2 of week 6 |
soc:2011:pcmattman:journal:week6 [2011/07/02 22:14] pcmattman day 7 log |
||
|---|---|---|---|
| Line 12: | Line 12: | ||
| 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 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! | ||
| + | |||
| + | ==== Day 3 (June 29) ==== | ||
| + | |||
| + | I was busy with real-world commitments this evening. | ||
| + | |||
| + | ==== Day 4 (June 30) ==== | ||
| + | |||
| + | 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 :). | ||
| + | |||
| + | ==== Day 5 and 6 (July 1, July 2) ==== | ||
| + | |||
| + | 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). | ||
| + | |||
| + | ==== Day 7 (July 3) ==== | ||
| + | |||
| + | 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. | ||
