Package Details: wide-dhcpv6 20080615-15

Git Clone URL: https://aur.archlinux.org/wide-dhcpv6.git (read-only)
Package Base: wide-dhcpv6
Description: An open source implementation of DHCPv6 developed by KAME project (with Debian patches)
Upstream URL: http://wide-dhcpv6.sourceforge.net/
Licenses: custom
Submitter: Foucault
Maintainer: Foucault
Last Packager: Foucault
Votes: 7
Popularity: 0.000178
First Submitted: 2013-07-27 23:47
Last Updated: 2019-04-14 10:14

Latest Comments

« First ‹ Previous 1 2 3 Next › Last »

2bluesc commented on 2014-07-08 21:22

I don't know how common it is to have multiple (full disclosure: I don't need it) dhcpv6 interfaces, but I see no reason to limit AUR users wit this. I'm following the spirit of netctl and friends that use instances per interface.

The dual systemd service file will work, but seems distracting. This AUR package doesn't need to cater to me, but I think my requests are more generic and is why I brought them up -- to hopefully improve the usefulness for everyone.

@Foucault the revised conf files make sense as well, but we need to be careful of all the systems that will break when it changes. That's how my original frustration came about. :)

Foucault commented on 2014-07-04 16:03

Well that's an (unexpectedly) heated discussion!

What could be done is to provide both a dhcp6c@.service and dhcp6c.service file (that's what the dhcpcd package does for example). Then everyone is happy although at the moment the only advantage that %I provides is the ability to spawn multiple instances of the program for many interfaces. Is it *that* common though (honest question)?

I would not like to change the environment variable names though, since in my opinion more descriptive variables are better (within reasonable limits, of course), as in "self-documenting". The conf file name choice was a bit poor indeed and it would be better to change it to something more sane (/etc/conf.d/dhcp6c.conf or something). Same thing goes with the sysconfdir, which is named after the program. It is reasonable to use "wide-dhcpv6" as the dir name since this is how the program is named and it would help to avoid confusion with other dhcp programs (ISC, dhcpcd, whatever). "dhcpv6" is a bit vague and I am not willing to change that (FYIW, debian also uses wide-dhcpv6).

Foucault commented on 2014-07-04 16:02

What could be done is to provide both a dhcp6c@.service and dhcp6c.service file (that's what the dhcpcd package does for example). Then everyone is happy although at the moment the only advantage that %I provides is the ability to spawn multiple instances of the program for many interfaces. Is it *that* common though (honest question)?

I would not like to change the environment variable names though, since in my opinion more descriptive variables are better (within reasonable limits, of course), as in "self-documenting". The conf file name choice was a bit poor indeed and it would be better to change it to something more sane (/etc/conf.d/dhcp6c.conf or something). Same thing goes with the sysconfdir, which is named after the program. It is reasonable to use "wide-dhcpv6" as the dir name since this is how the program is named and it would help to avoid confusion with other dhcp programs (ISC, dhcpcd, whatever). "dhcpv6" is a bit vague and I am not willing to change that (FYIW, debian also uses wide-dhcpv6).

2bluesc commented on 2014-07-04 15:40

Short response:

The "wan0" is an example. The average Arch Linux user is more then competent enough to substitute the appropriate interface in there. If they want to use links, fine, the name of the interface and how it comes to exist is irrelevant.

The point is that my solution supports multiple network interfaces, I will avoid using wan[0..] as it appears distracting.

Remembering interfaces is not hard. Bash and zsh will even tab-complete them `systemctl status dhcpv6<tab-tab>` if the right packages are installed and the service(s) is/are enabled. Also `systemctl list-units dhcp6\*` is easy enough for the once per year AUR breakage that users may need to remember their interfaces. Very rarely do I need to manage wide-dhcpv6 except after my last update where this startpd.conf file broke all my IPv6 systems.

The environments file will always break the ability to have multiple interfaces running dhcpv6 as I've explained before because it assumes only 2 are possible. Again, the average Arch user is a power-user and I suggest a solution that doesn't restrict their ability to use a service. Occam's razor applies here and selects the simpler config file that's actually more powerful.

And I don't mean to nit-pick your service file about things like %I and the PID file other then to point them out so we as a community can clean them up and resolve them.

Anyone else have comments or opinions?

thx1138 commented on 2014-07-03 20:47

I'm including some man page references for the benefit of anyone following this thread, and not to insinuate that you had not read them. :) The systemd documentation is a bit "spread-out". I appreciate you examining the ".service" file.

> Judging from your comments it's just to prevent you from having to remember
> your systemd instances.

Yes, exactly. You may scoff, but when configuring different machines, or changing the hardware on a machine, or swapping interfaces on a machine, remembering the correct unique interface identifier can be error prone. It is bad enough, when changing an interface name, that multiple configuration files must be modified - for systemd-networkd, dnsmasq, dhcp6c, and whatever else.

Another alternate approach is to modify the interface names to something generic only once, using "/etc/systemd/network/<interface>.link" files, and then to use the generic names everywhere else. But then, that special ".link" file must be written first.

> 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.

1) Arch uses unique identifier names for interfaces, not "wan0", and so on.

2) "goes in the face of systemd" is unfair, since systemd also supports "EnvironmentFile=", as well as "Environment=", as described at "man 5 systemd.exec". Rather, it is a matter of using an "Environment File" approach or a "Template File" approach for the ".service" file, at "man 5 systemd.unit". Or, using interface re-naming, at "man 5 systemd.link", or using unique ".service" files in "/etc/systemd/system/".

"systemd" supports all of these approaches.

3) Using special ".link" files and the generic "wan0" and "wan1" may be more elegant, as the WAN interface changes back and forth, for instance, between the hardwired interface and the wireless interface, but then "something" will have to issue a sequence of explicit "systemctl" commands to enable, disable, start, and stop the changing WAN interfaces, and also, to modify all the other network configuration files to reference the correct "wan0" or "wan1", including the dhcp6c configuration file, and then, to "restart" these other network daemons. This dynamic networking scenario is something much more complex than a simple static-interface wide-dhcpv6 install. Admittedly, the Environment File approach, by itself, does not solve this dynamic configuration problem. Neither can NetworkManager or systemd-networkd yet provide Prefix Delegation for dynamic interfaces.

4) Alternatively, using special ".link" files and a single generic "wan0", which was then dynamically associated with the active WAN interface, would still require modifying every other configuration file with network interface references, to reference "wan0" explicitly. If and when systemd-networkd gains the ability to handle dynamic network configuration, then a generic "wan0" approach would have an advantage. By then, systemd-networkd presumably would also automatically issue a "restart" to all the active network daemons, after changing the active "wan0" WAN interface.

5) The current dhcp6c has its own problems, in that, even though the man page shows "interface" as a required command line parameter, in actuality, dhcp6c will "glom" all of the active interfaces. And, even when the Template File approach to the ".service" file is used, the dhcp6c configuration file at "/etc/wide-dhcpv6/dhcp6c.conf" _has_ to reference the correct WAN interface, to request a Non-temporary Address and a Prefix Delegation, and the correct LAN interface to apply the correct Site-Level Aggregator address. So, issuing a "sudo systemctl start dhcp6c@<some_WAN_interface>" along with a "dhcp6c.conf" file specifying "some_different_WAN_interface", is going to cause problems.

I did try running "dhcp6c" without any interface argument. It fails. I even tried running "dhcp6c" with a bogus interface argument. That fails too. But then, it is also silly to require an interface argument to "dhcp6c", since the config file _has_ to match the WAN interface and the LAN interface. _There's_ a project opportunity for someone, cleaning-up wide-dhcpv6 a bit.

6) Accidentally starting dhcp6c on the "wrong" interface is going to be a mostly "silent fail", since dhcp6c will start just fine, but still not do the right thing.

> 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.

In my defense, that was not me. ;) The reference should be "${WAN}" or "${DHCP6C_WAN}", whatever, when using an Environment File approach, and "%I" and "%i" when using a Template File approach, described at "man 5 systemd.unit". Yes, the "Description=" entry should be corrected.

> 2. Why is a pid file being written if nobody is using it? In a post- SYSVINIT
> era, these are just noise.
> 3. Exec stop is over verbose, systemd would send the TERM signal correctly
> anyways

Ok. I was not sure if systemd needed the pid file to track "$MAINPID". I was following the example at "man 5 systemd.service". But, since dhcp6c is made to run with "-f", non-forking, I suppose that tracking the PID is not a problem for systemd. In any case, dhcp6c is _still_ going to write "/var/run/dhcp6c.pid", by default, and the dhcp6c command line switch merely illuminates this default. You could write a patch for dhcp6c, I suppose, to stop it writing a PID file. ;) The "ExecStop" entry seems to be the default also.

Yes, the "[Service]" section can be simplified.

> Then of course the service name is "dhcp6c@wan0" and everyone is happy

The literal command "sudo systemctl start dhcp6c@wan0" will fail, since there will not be a "wan0" interface, without writing a special ".link" file, which would also require modifying all other configuration files referencing the WAN interface, and restarting all other network daemons when "wan0" references a changing WAN interface.

This is mostly a matter of personal preference, though, using a Template File approach for the ".service" file and remembering the unique identifier names or using an Environment File approach for the ".service" file and writing a config file with "WAN=<interface>", or writing special ".link" files to create generic interface names for the Template File approach, or just writing a unique ".service" file for each running dhcp6c.

I believe that explicitly writing and storing "WAN=<interface>" in a config file, to match the "dhcp6c.conf" file, and assuming there is only one WAN interface, will be simpler and less error prone than memorizing which unique interface identifier goes where for every interface on every machine managed - or writing special ".link" files or unique ".service" files.

Obviously, the ".service" file can be customized, after an install. Months later, I think remembering "dhcp6c", rather than "dhcp6c@<what_interface_was_that_anyway>", is going to be easier.

On a tangent, I would prefer to have "--sysconfdir=/etc/dhcpv6", instead of "--sysconfdir=/etc/wide-dhcpv6". The name is more succinct, and there is no name clash, with all the other "dhcp's".


James

thx1138 commented on 2014-07-03 11:10

2bluesc commented on 2014-07-02 14:52

@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. :)

thx1138 commented on 2014-06-28 05:56

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

Foucault commented on 2014-05-18 21:21

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.

thx1138 commented on 2014-05-18 20:42

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