Thread: [Ddclient-support] Support for IPv6 (patch)
Brought to you by:
supersandro2000,
wimpunk
Menu
▾
▴
ddclient-support
|
From: Eduardo T. <etr...@gm...> - 2011-09-10 05:08:39
|
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. |
|
From: Eduardo T. <etr...@gm...> - 2011-09-12 13:19:36
|
>> 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 us...@te... 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*. >> "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 |
|
From: Eduardo T. <etr...@gm...> - 2011-09-12 15:52:21
|
>> 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
> chunk looks suspicious:
>
> + 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]
>> 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
|
|
From: Felix L. <fel...@gm...> - 2011-10-31 18:14:01
|
For some reason I cannot read all messages in this thread, but I would like to second Eduardo's request for the new ipv6 feature. >From the abundance of ipv6 addresses it may seem that 'ddclient' has no use in the future, but that is not true. Several ipv6 transition scenarios, including Teredo, involve dynamic addresses (although no NAT). One could, and perhaps should, use 'ddclient' for relaying corresponding updates to dynamic DNS. Eduardo's solution to separate ipv4 and ipv6 makes great sense, because one can serve both protocols both from different equipment. Many free hosting plans provide only ipv4. Serving ipv6, on the other hand, is uncomplicated even when behind NAT and requires no port forwarding. Hurricane Electric (he.net) offers dynamic DNS for A and AAAA records. I would like to use 'ddclient' for that purpose. Sincerely, Felix |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X