So one of the main features of dhcpcd was the ability to add and remove addresses and subnets in accordance with interface preference and state. This worked very well in Linux, both for IPv4 and IPv6.
When I discovered FreeBSD and then NetBSD making dhcpcd work with the same features provided troublesome. For the IPv4 case, we needed to patch the kernel so that IFA_ROUTE remained sane. For the IPv6 case it was a lot more complicated as parts of the IPv6 stack rely on the kernel processing Router Advertisements instead of a 3rd party tool. Working this out was a lot more time consuming and complicated, but we got there with minimal fuss!
So as of now, dhcpcd can fully replace the NetBSD and Linux in kernel Router Advertisement handling code.
But why was I right after all these years? Because quite a few knowledgeable NetBSD folk assured me that the kernel was fine and it was likely dhcpcd at fault. As it turned out, it really was the kernels fault.
It's been an eventful two years of not blogging. Mainly as I got heavily involved in playing World of Warcrat, Star Wars: The Old Republic and now Guild Wars 2 and this is a technical blog not a gaming one.
Anyhoo, since GW2 is a lot more casual than the others the idea is that I have more time for working on open source stuff, like say dhcpcd. Well, I finally found some time over the past few months and put DHCPv6 INFORM support into dhcpcd. This is only triggered when dhcpcd recieves an IPv6 RA with the O flag set. Luckily, I put IPv6 RS support into dhcpcd a few months ago but didn't feel the urge to blog about it. Well, I do now!
Before the end of the year, I aim to have DHCPv6 IA support triggered via IPv6 RA with the M flag set as well. Do I have any other goals? Well, all my other projects are pretty much complete. One of the reasons why I starting gaming so much is that I'm pretty happy with the current state of affairs and anything else is just a bonus. That being said, there are a lot more DHCPv6 things to do besides IA support such as better separation between IPv4 and IPv6, moving to TAILQ lists intsead of our hand rolled and other misc stuff such as improving dhcpcd-dbus and dhcpcd-gtk.
dhcpcd-5.1.2 has been released with the following changes:
- ClientID is now reported when interface starts
-w, --wait forcesdhcpcd to wait until an interface gets a lease or times out
- 50-ypbind hook added for BSD style NIS
- Ensure DHCP socket is open when sending a DECLINE
- Uses new hwaddr if existing interface is downed and then changed.
- No longer works on firewire interfaces by default.
dhcpcd-5.1.2 has a new behaviour change - when starting up and at least
1 interface has a carrier then it tries to get a lease or times out. It
still daemonises regardless. This, along with the
-w flags allows
total control over the desired behaviour of dhcpcd.
So, I'm now finally natviely IPv6 enabled :)
This led to an interesting debtate about my internet connection. In a nutshell my Drayetk Vigor 100 is broken, but apparently by design. The problem is this - for IPv4 goes through my NAT whose public IP has an MTU of 1492 so Path MTU Discovery works fine. However IPv6 does not need NAT and the PPPoE interface does not have a public IPv6 and nor do the internal clients use it even it there was one. So the path MTU is 1500, which is too big for the PPPoE to handle.
The correct solution is to obviously terminate the IPv6 on a PPPoA connection, but only the Cisco 877 router does this and that's outside of my price range, even on eBay. One solution is to clamp the MSS on the router to 1430 so that all clients work. But this is a hack. The best solution with my hardware is to force the MTU to 1492 for all nodes inside my network, so they share the same MTU as the PPPoE so that Path MTU Discovery works.
You can see this working for yourself on IPv6 now, as this site is IPv6 enabled and sits behind the PPPoE link. You'll need to query IPv4 servers for the address though as I don't yet have a glue record for IPv6, but as I'm changing registrar that should change in a few weeks :)
Because of this, I've made the dhcpcd default to request and use the MTU value if offered by the DHCP server. You'll be seeing this in dhcpcd-5.0.5 (now out). dhcpcd-5.0.6 will feature restoring the MTU correctly between leases.