[Ddclient-support] Support for IPv6 (patch)

[Eduardo Trápani]

Hi,

I wrote a little patch for 3.8.1 to support IPv6 on the two services I
know that can handle it. Both dyndns and freedns automatically
recognize the type of address being passed to them and use it to update
the A or the AAAA record.

I added the "usev6" variable, that works exactly as the "use" one. So,
if you are using dynds and change use/usev6 on your existing definition
*and* you have a global IPv6 address you're all set.

For "usev6" only the "ip" and "if" strategies are implemented and the
"if" one uses "ip -6 addr list" instead of "ifconfig" because I find it
easier to parse and it doesn't need root privileges (Debian box).

So far the patch works for dyndns without problems, for an IPv6-only
host (well, it does have IPv4 but its a private address, the IPv6
address is public and comes from miredo/teredo).

Since the program hashes the hosts on the dynamic domain, it is not
possible to update IPv4 and IPv6 on the same service with the same
configuration file. I'm not that fluent in perl so I guess it's better
for the actual programmers to sort that one out.

Freedns forces you to have an IPv4 record that is used to build the
update url. The IPv6 update on that url works but the DNS servers can
take a long time to notice it. It's tricky.

I hope it helps somebody, it took me a while to figure it out.

Eduardo.

[Eduardo Trápani]

Post by Eduardo Trápani
I wrote a little patch for 3.8.1 to support IPv6 on the two services
I know that can handle it.

I'm not sure i understand.
DynDNS for IPv6 sounds like a terrible misconcept, a contradiction
all in itself.

I'm using a teredo client (transition technology) so I get an dynamic
IPv6 over an IPv4 tunnel, I'd like to be able to access it. I need a
name for that because doing:

ssh user@[2001:0000:4136:e378:8000:63bf:3fff:fdd2]

is not practical or, at least not so simple as:

ssh ***@teredohost.dyndns.tv

when you take into account that the host is miles aways from me, behind
a NAT router that changes its IPv4 address periodically. I'm actually
(and happily) using a name for dynamic IPv6 right now. So much for the
misconcept or contradiction. IPv4 just would not work, or I would have
to setup a VPN for incoming connections ( and believe me it's a lot
easier to do apt-get install miredo, and that's it).

I thought the whole point of IPv6 is to have enough addresses
such that everybody can have their own, proper addresses?

We found the misconcept and inner contradiction. There it is. Routing
and latency should ring an alarm with that idea of yours, not to mention
routing size tables. If you fly from the US to France, even if possible
(as with IPv4) I doubt you would want to keep "your own" IPv6 address
from the other side of the ocean for your mobile or your notebook. And
no, nobody would care to change transatlantic routes just for a user.
You would most likely want to pick up the hotel room or the university
IPv6 address, or the airport wireless one and then, you host will be
more easily found by using a name (dyndns to the rescue!). Of course
there are extensions for handling mobile, multihoming and staff like
that in IPv6 (also for IPv4) for example [1][2] but they are overkill
for most individuals.

Everybody is going to be addressable in IPv6, but nobody garantees you
will always have the same address wherever you go!! That's at least
naïve if you consider the impact that would have for moving users on the
size of the backbone routing tables.

So, may I suggest that the misconception lies on your side? If we had
enough IPv4 you would consider dynamic DNS "a terribly misconcept"? The
key concept here is not *address* but *dynamic*.

Post by Eduardo Trápani
"ip -6 addr list" instead of "ifconfig" because I find it easier
to parse and it doesn't need root privileges (Debian box).

Don't do that. The /sbin/ip command is utterly non-portable
and purely Linux-only, so it should not be used for anything
outside purely Linux-only contexts.

Ok, if you think this can make it into mainline I can change that.

Besides, using ifconfig(8) to query an IP address does not
require root privileges.

No, it doesn't, you're right. It's simply that Debian doesn't have
/sbin int its path for non root users. You have to add it or call
/sbin/ifconfig directly but you do not need root privileges.

Even if the basic concept would make any sense, i don't see
any patch anywhere.

The list didn't just let it through, please care to read the next
message on the same subject to find the link to the actual patch. I
copy it here[3] just in case.

About the basic concept, you might want to reconsider it. I'm not
proposing it, I'm using it already from dyndns.com and I've used it from
afraid.org. There will be dynamic IPv6, and not only during transition
(which will last long enough). Happily somebody is already letting us
avoid things like 2001:0000:4136:e378:8000:63bf:3fff:fdd2 and using
names instead. Teredo and 6to4 (on dynamic IPv4) are not rare, I just
tried to add support to ddclient because that's the client I use and
love, I tried to take the least invasive route (just a keyword).

It's your call to ignore the patch, rewrite it or do as you wish,
dynamic dns for IPv6 is out there, it's used and eventually, if it
proves useful it will be soported, if not by upstream as a patch in
Debian, with ifconfig not iproute2, I get it. In any case, I suggest
you revisit the whole IPv6 concept.

Friendly, Eduardo.

[1] Mobility Support in IPv6 http://tools.ietf.org/html/rfc6275
[2] Provider-independent address space
https://www.ripe.net/ripe/docs/ripe-510#2e
[3]
https://sourceforge.net/tracker/?func=detail&aid=3407066&group_id=116817&atid=676131

[Eduardo Trápani]

Post by Eduardo Trápani
No, it doesn't, you're right. It's simply that Debian doesn't have
/sbin int its path for non root users. You have to add it or call
/sbin/ifconfig directly but you do not need root privileges.

That seems broken. The directory /sbin typically contains various
utilities that normal users can legitimately execute to gather
information, like dmesg, mount, ping, route, sysctl...
In /usr/sbin, there is more useful stuff like apm, arp, chgrp,
dig, fs, groupinfo, host, iostat, etc. etc.
So deleting *sbin from the PATH looks rather stupid.

If your interested in understanding the reasoning please check this old
discussion[1], with the relevant information from the FHS. It's by no
means stupid. Arguable maybe, not stupid.

Hell, deleting *sbin from the PATH breaks sudo(8) on top of that.
Users can't even do things like "sudo halt" any longer if
they dont have *sbin in their PATH.

sudo lives in /usr/bin!! So this has nothing to do with it. Please
check your assertions.

So no, a PATH not containing /sbin is never sane, and i don't think
we need to care about it (it is well known that a default Debian
system usually requires some manual reconfiguration before it
becomes usable). Maybe the documentation should mention
that running ddclient(8) requires a sane PATH giving access to
common utilities (including ifconfig(8)).

I think I'd rather go back to ddclient, your knowledge or assumptions on
Debian and sane defaults and usability seem to be a little ... either
biased or outdated, just like the previous IPv6 ones. I just said a
normal user in Debian does not have /sbin by default in the path.
Ddclient *runs as root*. So that's not a problem!

A usev6 option might indeed make sense, allowing different strategies
for v4 and v6 to be used concurrently. However, in that case, this
+ my $use = '';
+ $ipv6 = 1 if (defined $config{$h}{'usev6'});
+ if ($ipv6) {
+ $use = $config{$h}{'usev6'} || opt('usev6');
+ }
+ else {
+ $use = $config{$h}{'use'} || opt('use');
+ }
This will only allow to set either v4 or v6, right?

For each entry, yes, that is the whole idea. To treat ipv6 hosts as
another host. For me it's hard to pretend it's like an MX or something
like that and add a parameter. It's hard because there is all the
strategy stuff.

Maybe it's possible to support both in parallel?

Yes, by adding two configuration entries.

It may require slightly more changes.
If not, then it might be better to support just "use = ipv6',
"use = ifv6", "use = webv6".

I started out the way you are suggesting. But I really didn't like the
idea of namespace pollution, if you see what I mean. "ifv6", "ipv6",
"webv6". And they would do basically the same thing as their non-6
counterparts. I'd call it configuration noise. Say you want to have
both ipv4 and ipv6:

You can have two lines like this:

protocol=dyndns2
usev6=if, if=teredo
server=members.dyndns.org
login=user
password='my$password'
myteredohost.dyndns.tv

protocol=dyndns2
use=if, if=ppp0
server=members.dyndns.org
login=user
password='my$password'
myteredohost.dyndns.tv

Then you would have, at the same time, updates for ipv4 and ipv6. Even
better, you *could* set different parameters to each one, whatever they
might be.

*BUT* the program hashes the definitions based on
'myteredohost.dyndns.tv' (as far as I can see, I've already stated I'm
not that fluent in perl). In my original message I mentioned that
problem and explicitily said I didn't know how to work around it.

I believe that it's better to have two definitions, one for ipv4 and one
ipv6 (as in the example above) and just a new keyword. I looks cleaner.

If ddclient(8) is to support ipv6 at all, them allowing to set both

It already does :). For dyndns at least in four or five Debian/Ubuntu
computers. Please keep in mind that not necessarily everybody will take
the same path as afraid.org / dyndns, that is parsing the address and
deciding which record to update (A or AAAAA). Some of them may decide
to have a completely different update url, for example.

families in parallel seems more attractive than being forced to
choose either, so i'd prefer the use/usev6 direction.

Lets say that to achieve the same result it looks nicer and it's easier
both on humans and on the parsing code:

use=if, if=ppp0
usev6=if, if=teredo
use=ip, ip=204.23.12.99

[use, usev6, if, ip]

than:

use=if, if=ppp0
use=ifv6, ifv6=teredo
use=ipv6, ipv6=2001:0::2

[use, usev6, if, ifv6, ip, ipv6]

Post by Eduardo Trápani
It's your call to ignore the patch, rewrite it or do as you wish,

Sorry, i don't have time for detailed testing and polishing
this afternoon, but perhaps later, or perhaps others have...

It's ok, no hurry. It works for me and has already paid off. Just
wante to share the results back. The tone of my sentence was because I
was in part reacting on the perceived uselessness of the patch. That's
settled.

Eduardo.

[1] http://lists.debian.org/debian-devel/1999/12/msg00946.html