Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
soc:2011:pcmattman:journal:week8 [2011/07/15 02:26]
pcmattman day 4 log
soc:2011:pcmattman:journal:week8 [2011/07/16 22:45]
pcmattman day 7 log
Line 32: Line 32:
  
 So far so good though. 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! :)
 +
 +==== Day 6 (July 16) ====
 +
 +I implemented the changes to settings.h today. This has gone very well so far:
 +<​code>​26711 2957.453307 2001:​44b8:​1::​6 2001:​44b8:​7222:​a50:​20c:​29ff:​fe54:​c23d DNS Standard query response AAAA 2001:​470:​1f07:​121b::​1</​code>​
 +
 +That's an AAAA response to gPXE querying "AAAA flash6.etherboot.org"​ - all over IPv6! The nameserver was obtained via DHCPv6.
 +
 +I still need to implement some way for DHCPv6 to get enough information out of a router solicitation to make an address assignment globally routable, but that won't take too long at all. I think I can even do it without having to change too much of the existing router solicit code.
 +
 +**Update (0039 UTC):**
 +
 +I've managed to fix some routing issues in IPv6 and rework router solicitations as needed to allow DHCPv6 to get information about the routers and prefixes available. This means DHCPv6 can now assign a fully routable address, rather than having to assume the address is a /128 or something.
 +
 +This means DHCPv6 is essentially "​complete"​ in the sense that it can be used as a complete alternative to SLAAC. It does not yet have any features related to network booting, nor does it have features that gPXE's DHCPv4 implementation has such as caching.
 +
 +I just need to merge and rebase the commits related to DHCPv6 and rename and reimplement the "​ipv6"​ command now that this is complete. The complete user-visible IPv6 interface is now essentially complete; the remainder of my project is backend work.
 +
 +==== Day 7 (July 17) ====
 +
 +I **FINALLY** implemented time out handling for router solicitations today, which means gPXE won't hang anymore if a router advertisement daemon isn't available on the network. This let me try out DHCPv6 without any router advertisements - and it worked as expected. It assigned a /128 address, which was not able to be routed.
 +
 +I also fixed some interesting bugs from the past couple of days in the DHCPv6 code and updated the NDP router solicit code a bit to send a source link-local address with router advertisements (which helps the router avoid sending a neighbour solicit). I also managed to find a bug in the NDP code where the layout of "​struct router_advert"​ was incorrect, causing the flags such as OTHERCONF and MANAGED to never be seen. This was fortunately easy to resolve, and now gPXE can ask for only DNS information on a network where router advertisements are used for autoconfiguration (ie, mine! :) ).
 +
 +During my testing I have noticed that there are a few issues with the neighbour solicit/​advertisement code, which I will be looking at soon. The biggest issue so far is that processing of neighbour advertisements makes some rather significant assumptions about the layout of the incoming packet. I'd like to change that to parse the options in the packet and handle each as necessary.
 +
 +I also made some ip6mgmt.c changes today. These basically mean DHCPv6 only gets used in environments where router advertisements are not available, or where router advertisements suggest using a DHCPv6 server for additional configuration. I think this command is well and truly ready to be renamed from "​ipv6"​ to something more like "​ipv6-enable"​ or something, but I'm not sure exactly what to name it.

QR Code
QR Code soc:2011:pcmattman:journal:week8 (generated for current page)