Arch Linux User Repository

@thx1138 I have some disagreements with your systemd service, primarily that it's more complicated then needed: 1. Why and what is startpd? I assume "pd" stands for prefix designation but have no clue what it's for from the name (or what package it relates to). Judging from your comments it's just to prevent you from having to remember your systemd instances. Unfortunately this goes in the face of systemd and your solution doesn't scale to more then one dhpc6 server and one dhcp6 client. What if I have multiple interfaces? Systemd's instances will handle "dhcp6c@wan0" "dhcp6c@wan1" without any problems and with less work. I vote to remove startpd.conf and use "%I" instead of "$DHCP6C_WAN" from the systemd service file. Furthermore, the presence of "%I" in the Description (at the time of writing) tells systemd to expect an instance, but the lack of "@<instance name>" for the service confused me until I read the comments on this AUR to understand the history. Many other systemd services use the instance notation, most notably netctl@<if>. 2. Why is a pid file being written if nobody is using it? In a post- SYSVINIT era, these are just noise. Let's not do this if nobody is using it. 3. Exec stop is over verbose, systemd would send the TERM signal correctly anyways (ref: http://www.freedesktop.org/software/systemd/man/systemd.kill.html) Consequently, when the default device doesn't exist (as it won't for most, kill signal is inadvertently run see (ref: https://gist.github.com/anonymous/9ec6f6f684a5fcb45dd0 ). Let's stick to the defaults. Simpler more robust systemd.service $ cat /etc/systemd/system/dhcp6c@.service [Unit] Description=WIDE-DHCPv6 Client on interface %I After=network.target Requires=network.target Before=dnsmasq.service Before=NetworkManager.service Documentation=man:dhcp6c(8) man:dhcp6c.conf(5) [Service] ExecStart=/usr/bin/dhcp6c -c /etc/wide-dhcpv6/dhcp6c.conf -f %I ExecReload=/usr/bin/kill -s SIGHUP $MAINPID [Install] WantedBy=multi-user.target Then of course the service name is "dhcp6c@wan0" and everyone is happy :) Also, I agree with your comment about this not being in the main repos. :)

I've only just noticed your note about testing the revised package. Yes, that should work fine, but a few comments. I had thought to use the "environment" file to specify the "WAN" and "LAN" so that there was less chance to mix them, or to mis-spell the unique identifier names. The variables are not necessarily limited to use by wide-dhcpv6, and so the variable names could reflect a more general use, such as simply "WAN" and "LAN". But that is maybe not worth the trouble, for now. I suppose there could instead have been an "/etc/default/dhcpv6". What would be the difference between "/etc/conf.d/<file>" and "/etc/default/<file>"? It seems silly and confusing to have both locations in Arch. Also, it might be nice to include my working client config file, "/etc/wide-dhcpv6/dhcp6c.conf", as the "stock" sample config is not very complete. It would be easy to include the config file in the AUR tarball, and then install the new config along with the stock sample config, giving the stock sample config a different name, like "dhcp6c.conf.sample". Here I show my client config file, "dhcp6c.conf", where I've left in some notes: # wan=enp0s7 # lan=enp4s0 # man 5 dhcp6c.conf interface enp0s7 { # external facing interface - WAN send ia-na 1; send ia-pd 1; send rapid-commit; request domain-name-servers; request domain-name; # Not actually using the dhcp6c-script file here - # script "/etc/wide-dhcpv6/dhcp6c-script"; # send authentication <authname>; }; id-assoc pd 1 { # prefix delegation request # prefix <ipv6-prefix> <pltime> [<vltime>]; # request a specific prefix. # pltime and vltime are the "preferred" and "valid" lifetimes of the requested prefix. prefix-interface enp4s0 { #internal facing interface - LAN sla-id 0; # site-level aggregator - SLA - subnet address ifid 1; # IP address "postfix". Default is the EUI-64 address of the interface. Can be any desired subnet address, in decimal. # Combined with SLA-ID prefix to create full IP address of interface. sla-len 0; # prefix bits assigned. Take the prefix size you desire, something like /48 or /56 or just /64, and # subtract it from 64. If assigned a /56, 64-56 = 8 # Default value is 16, which assumes a /48. }; }; id-assoc na 1 { # non-temporary address allocation request # address <ipv6-address> <pltime> [<vltime>]; # request a specific address. # pltime and vltime are the "preferred" and "valid" lifetimes of the requested address. }; # authentication <authname> { # protocol delayed; # algorithm hmac-md5; # rdm monocounter; # replay-detection-method # }; # keyinfo kame-key { # realm "kame.net"; # keyid 1; # secret "5xnrt8irOKD16otstK1y=A=Z"; # }; And, I suppose that there should be a post-install note, warning people to edit that "environment" file, "/etc/conf.d/startpd.conf", where, for now, only the name of the "WAN" interface is used, by "dhcp6c.service". Thanks James

Hi! Thanks for your valuable input. I have encountered the same problem with dnsmasq and I just removed the user from the service file of dnsmasq (although that's not very safe, but anyway). dhcpcd works ok though. I moved the startpd.conf to /etc/conf.d/startpd.conf since that seems a more natural place for config files. I also changed the env variables to DHCP6C_WAN and DHCP6C_LAN. Can you try the following source package before I upload it to AUR? https://dl.dropboxusercontent.com/u/17449858/aur/wide-dhcpv6-20080615-10.src.tar.gz I believe wide is not in repos because is practically not maintained any more and there are more recent projects that support PD correctly these days. dhcpcd will cover about 90% of the PD issues that users have.

I also used the patch from sourceforge, at http://sourceforge.net/p/wide-dhcpv6/patches/2/, "000_renew_patch", adding http://sourceforge.net/p/wide-dhcpv6/patches/_discuss/thread/e139c58f/14bc/attachment/000_renew_patch to the PKGBUILD "source=" set, since it appears that this patch has not been incorporated into the Debian patch set. BTW, when running the dhcp6c client on the WAN, alongside the dnsmasq server on the WAN: There seems to be a minor bug in dhcp6c in that it will bind to the LAN interface, even though only the WAN interface has been specified on the dhcp6c command line. With this, the current Arch version of dnsmasq, 2.70-1, has "--user=dnsmasq" on the dnsmasq.service ExecStart command line. And so, dnsmasq, running as user dnsmasq, does not have permission to bind to the LAN interface, after waiting for dhcp6c to configure an IPv6 Prefix Delegation address on that interface. The simple solution is to remove "--user=dnsmasq" from the ExecStart command line, so that dnsmasq runs as user root. The more complicated solution is to fix dhcp6c, so that it does not bind its client service to an interface which has not been specified on the command line, as described at "man 8 dhcp6c". I don't have a patch for this. Also, dhcp6c effectively provides a systemd "state" to allow triggering a subsequent service. I added "Before=dnsmasq.service" in "dhcp6c.service". So here is a dhcp6c.service file, an alternative to "dhcp6c@.service". Please use this one in the AUR package, if you like it. Here, "$wan" is provided in an EnvironmentFile, in "/etc/systemd/startpd.conf", instead of having to remember a WAN interface name when running "systemctl". My environment file has "$wan=<WAN interface name>" and $lan=<LAN interface name>" so that I don't have to remember which one is which, especially whenever I swap them around. Also, so far, I have had no reason to need "Restart=on-failure". It "just works". It especially works very nicely with dnsmasq providing "dual-stack" DHCP and DHCPv6 services on the LAN interface and, for now, systemd-networkd providing IPv4 DHCP on the WAN interface. dhcp6c adds the DHCPv6 client services to WAN interface. [Unit] Description=WIDE-DHCPv6 Client on interface $wan After=network.target Requires=network.target Before=dnsmasq.service Before=NetworkManager.service Documentation=man:dhcp6c(8) man:dhcp6c.conf(5) [Service] EnvironmentFile=/etc/systemd/startpd.conf # User=dhcp6c # Group=dhcp6c ExecStart=/usr/bin/dhcp6c -f -c /etc/wide-dhcpv6/dhcp6c.conf -p /var/run/dhcp6c.pid $wan ExecReload=/usr/bin/kill -s SIGHUP $MAINPID ExecStop=/usr/bin/kill -s SIGTERM $MAINPID # Restart=on-failure # RestartSec=2 [Install] WantedBy=multi-user.target Also, what is this package doing the AUR instead the main repositories?! I was surprised to find that dhcp6c is simple and effective. Even though the last "official" release is from 2008, I also see here that Debian - and Arch AUR now - maintain a patch set for this product. After some searching, I suspect that this dhcp6c DHCPv6 Client is the only "featureful" one that actually _works_. "Featureful" in that, in addition to requesting a Non-temporary Address, it also allows requesting a Prefix Delegation, _and_ allows specifying a Site-Level Aggregation Identifier length/Prefix "hint" _and_ automatically configures a LAN interface with the prefix combined with a configurable SLA ID and an Interface ID, _and_ supports router authentication. With IPv6 now becoming widely available from ISPs, and with dhcp6c being one of the only functional easy-to-use DHCPv6 Clients, I'm thinking that this package needs some more main-stream love. Of course, some day, systemd-networkd may just do DHCPv6 itself. And thanks for adopting this package Spyros! I had been really hesitant to even try it. James

Thank you very much!

This PKGBUILD must include: https://dev.openwrt.org/browser/packages/ipv6/wide-dhcpv6/patches/000-cftoken-noyywrap.patch so it can be successfully compiled.