IPv6 configuration

[kriswema]

How can I set it up to preferably use an IPv6 address rather than IPv4? Does inadyn even support IPv6? I'm using Dyn, which gives me the possibility of entering IPv4 and IPv6 addresses.

[troglobit]

Hi!

Sorry, but IPv6 is currently only supported with https://tunnelbroker.net/ ... patches to fix this are most welcome! :)

[ThomasWaldmann]

bummer, i just thought i give inadyn a try as ddclient doesn't support ipv6.

it's a pity how few dyndns clients support ipv6.

btw, I develop https://nsupdate.info/ and it supports ipv6. it even has support for updating all your v6 IPs on your lan with a single dyndns2 update request. so, if you have questions about how dyndns2 protocol / services / clients can easily support ipv6, i can help. Can't help with C coding / C specific questions though.

btw, in python-dyndnsc, a nice socket-based method to find the right local ipv6 address was just implemented:

https://github.com/infothrill/python-dyndnsc/blob/develop/dyndnsc/common/detect_ip.py

[troglobit]

Good to know, thanks for the offer @ThomasWaldmann :-)

[ahknight]

Any movement on this, perhaps? It's starting to get pretty important now that TWC and Comcast have started handing out IPv6 subnets to home users and there's talk of some mobile networks going IPv6-only within a couple of years now that many countries have allocated their last IPv4 address. :(

[troglobit]

Nope.

Unfortunately I cannot get an IPv6 at home yet, so we're short out of luck until some friendly soul submits a pull request. 😞

[ThomasWaldmann]

@troglobit you really need tunnelbroker (HE, hurricane electric), for multiple reasons. :)
They seem cool, even have IPv6 quizzes and stuff. And it's free.

BTW, nsupdate.info can trigger a tunnelbroker update if it receives a normal, single v4 dyndns update.

[troglobit]

@ThomasWaldmann heh, OK I'll give tunnelbroker a go first thing tomorrow! 😃

Good to know about your nsupdate.info capabilities as well. Issue #83 though mentions they have something similar ...

[troglobit]

So, as of 740abac Inadyn now supports using an external command to query the address, which also supports parsing IPv6 addresses. So far I've only tested it using the following script

checkip-command = "/sbin/ifconfig wlp3s0 | grep 'inet6 addr'"

Which finds the IPv6 address and then sends the update, as a string, to the DDNS provider. If anyone else could give it a whirl with the standard provider setup I'd be very happy! 😃

This latest set of commits brings the v2.0 release very close, so any feedback is greatly appreciated.

[ThomasWaldmann]

likely that is not enough to find out the right ipv6 address for that purpose.

with privacy extensions, an interface has a bunch of ip addresses, but they are just temporary - while you want the permanent one to register it with a dyndns service.

python dyndnsc has some code to find the right one - have a look there.

[troglobit]

Sure, my point was simply that it is now possible to use IPv6 with Inadyn. The following script would likely work better :)

checkip-command = "ip address show scope global dev eth0 |grep inet6"

But you're right, the iface = eth0 detector doesn't handle IPv6 at all, and there is no provider {} section with IPv6 support yet either.

[troglobit]

I finished another function, now the iface = eth0 setting can return IPv6 addresses as well. There is an IPv4 and IPv6 validator that filters out local/non-global addresses,

Only thing missing now is for someone to create a IPv6-provider :-)

[ThomasWaldmann]

You still need to determine the permanent (non-privacy-enhanced) address as it does not make much sense to put the temporary ones into dns.

[troglobit]

Admittedly I'm by no means knowledgable about IPv6 but I've used the following standardized verifiers in is_address_valid():

• IN6_IS_ADDR_UNSPECIFIED(): Unspecified address
• IN6_IS_ADDR_LOOPBACK(): Loopback address
• IN6_IS_ADDR_LINKLOCAL(): Unicast link-local address
• IN6_IS_ADDR_SITELOCAL(): Unicast site-local address

From http://pubs.opengroup.org/onlinepubs/000095399/basedefs/netinet/in.h.html and I've tested with a few obvious ones. From the attached table.

Any help here would be greatly appreciated!

[ThomasWaldmann]

Can't help you with the C stuff, but here is working python code:

https://github.com/infothrill/python-dyndnsc/blob/8a598fad7ec76fd9b979250fd851b3a2fe4ea32d/dyndnsc/common/detect_ip.py#L74

IPV6_PUBLIC (not _TMP) is what you want.

[troglobit]

Due to the way I've chosen to implement the new "get interface address" code (portability reasons), I cannot use the same (Linux specific) socket API that the Python code does.

However, I now understand what needs to be done, and for future reference I'm posting a few links and thoughts for myself:

• https://www.ietf.org/rfc/rfc5014.txt
• https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/apis/inet6_is_srcaddr.htm

The inet6_is_srcaddr() API is missing in GLIBC on Linux, and also on the BSD's. It seems only IBM have implemented RFC 5014 as a separate function, as recommended. Linux only has this support as an extension to the socket API, which is useful but very limiting.

Implementing this function according to the RFC, possibly in libite so it can be reused by other applications as well, should be quite straight forward.

[acolomb]

I've been thinking about how to tackle the rest of IPv6 support in Inadyn. Before sharing my plans thus far, what do others think about this one specific question:

Should a single provider section in the config handle both IPv6 and IPv4 addresses, or would it be acceptable to require two separate configuration sections?

I personally think the former way is superior. Only one HTTP update request, only one point to specify the user credentials, and it could be extended to support other record types in one go, e.g. setting the MX address. I'll also try to come up with a backward-compatible configuration syntax for these extensions.

[acolomb]

I started collecting some notes about what needs to be done to complete Inadyn's IPv6 support at https://github.com/acolomb/inadyn/blob/ipv6-planning/IDEAS-IPv6.md .

Requesting for comments, so we have a consensus before I start prototyping features.

Maybe this could be turned into a GitHub "project", but I haven't played with that feature enough yet. Splitting off this issue for several sub-aspects would be useful as well.

[driesmp]

Would be nice to get IPv6 support in a ddns client :). Any updates on progress?

[acolomb]

I've started to hack on this again last weekend. Can't give you any estimate, though, since my free time is quite limited currently.

Keep an eye on my fork mentioned above to see any progress :-)

[jorhett]

FWIW I have IPv6 updates to Google working just fine with the following

• QNAP

  • checkip-command = "ip -6 address show scope global dev eth0 |grep inet6"

• macOS

  • checkip-command = "ifconfig en0 |grep inet6 |grep -v temporary"

[jorhett]

@acolomb Reading your DOC have a few comments:

• No reason to do anything with MX records. They can only target names. They will persist even if the name disappears and reappears later.
• Likewise aliases. A CNAME to a ddns name will persist and do the right thing. Not our problem.
• Determining the primary permanent IPv6 address on most posix nodes is fairly trivial with the ip command set, I think doing the obvious thing by default and allowing checkip override for customization is the way to go (e.g. don't overthink this)
• If a node has an IPv6 address outside of fe80/10, we should be registering the IPv6 and ignoring the v4 unless instructed otherwise. Very few people have workable IPv4 addresses that can dynamically accept connections from the NAT firewall they are hiding behind.

And finally, dual updating both v6 and v4 isn't supported by any provider AFAIK and makes the job harder. I believe very strongly that you should aim for MVP of simply getting IPv6 working "out of the box" with every provider that supports it. Don't shoot for complexities that aren't required until the basic support is there.

[jorhett]

As a note: if anyone has a node where IPv6 isn't working and they are willing to share the output of ip and ifconfig commands along with credentials to test with, I'm happy to work on IPv6 implementations. Ping me directly.

[jorhett]

So I've read through @acolomb's writeup and here's my opinion:

• The vast majority of providers support DynDNS protocol, which is careless (literally) about which type of address you send it. You can send it either type or both comma-separated

So really the only thing we need to make inadyn truly dual-stack would be

1. A selection mechanism for which protocol to send (@acolomb proposed addrtype)
2. Separation of check-ip commands for v4/v6
3. A list of commands to check v6 IPs on different platforms, much like v4 today

I really think that achieving this point will be quite easy.

[acolomb]

@jorhett Sorry for not responding earlier, your questions slipped off my radar.

* No reason to do anything with MX records. They can only target names. They will persist even if the name disappears and reappears later.

* Likewise aliases. A CNAME to a ddns name will persist and do the right thing. Not our problem.

Thanks for your opinion. I had crossed them off my mental list already, but who knows what other record types with a dynamic nature might come later, so having an extendible scheme would not hurt if it does not make things more complicated.

* Determining the primary permanent IPv6 address on most posix nodes is fairly trivial with the `ip` command set, I think doing the obvious thing by default and allowing checkip override for customization is the way to go (e.g. don't overthink this)

The main problem (unsolved and discussed way above in this issue) is the advertisement of temporary addresses that will soon be retired because of the IPv6 Privacy Extensions feature. Filtering for ip address show output for global is not enough, I think the temporary flag needs to be avoided as well. The mngtmpaddr flag seems to be a good indicator of having the correct address, if it exists.

* If a node has an IPv6 address outside of `fe80/10`, we should be registering the IPv6 and ignoring the v4 unless instructed otherwise. Very few people have workable IPv4 addresses that can dynamically accept connections from the NAT firewall they are hiding behind.

I don't know about the majority or other statistics, but there are definitely still many ISPs issuing real IPv4 addresses. On the other hand, I've seen technically up-to-date campus networks deployed without IPv6 routing enabled, which is clearly a bug but warrants not ignoring IPv4 completely if IPv6 seems to be working on our end ("server").

And finally, dual updating both v6 and v4 isn't supported by any provider AFAIK and makes the job harder. I believe very strongly that you should aim for MVP of simply getting IPv6 working "out of the box" with every provider that supports it. Don't shoot for complexities that aren't required until the basic support is there.

First of all, Dynu for example supports both IPv6 and IPv4 updates in one query, and I believe they are not alone. I understand your concern and I wish I had more time to move toward a better IPv6 solution overall. My goal in writing that design document was to envision a final feature set and its needed configuration syntax, so we won't have to change the configuration syntax again once the MVP grows toward the full-fledged flexible solution. One design requirement, rather important IMHO was to allow reusing checkip sources and also allowing fallbacks. In the simplest case, two providers each have their own checkip servers, but each could fall back to the other's determined address when one is down.

Will reply to your PR shortly.

[acolomb]

Actually the "alias" stuff also comes from Dynu. It's their term for subentries in the zone, e.g. you can set example.dynu.net to some IP and also create an A or AAAA record for www.example.dynu.net. Updating that in a protocol request needs a combination of hostname=example.dynu.net&alias=www IIRC.

[jorhett]

quick TL;DR--agreed on the aliases and dual update. Both are part of the DynDNS2 protocol (I misread the first time)

I don't agree on building a scheme capable of handling unknown protocol changes. It took 20 years for AAAA records to become standardized, I seriously doubt we're at risk of an overnight need for a different type of record. (I work on those committees and if you saw the political and social barriers to change you'd understand how unlikely it is). This is not a serious risk, whereas overdesign is ;-) Let's get an MVP in place.

But... the code is very single-threaded check-1, submit-1 today. The work to make it deal with an either/or/and scenario for v4/v6 is going to make it more modular, likely enough so that adding another type should be easy. So you may get what you want, it's just not going to be a priority focus (for me anyway)

[acolomb]

We can probably agree that IPv4 and IPv6 are all address types that are needed now. Let's not get confused with "address types" (or families as in socket-speak) and DNS "record types". Whatever record type, it can currently only hold either of those two meaningful dynamic address types.

However, I favor my third proposal which explicitly suggests source-ipv4 and source-ipv6 config entries and otherwise keeps the old option names backwards-compatible. If those are used, the semantics should be to auto-detect what type is needed. Only if you need both IPv4 and IPv6 is when the new syntax is definitely needed, and then adding a source-ipv8 type in 200 years will be almost a no-brainer ;-)

[troglobit]

(I sincerely hope Inadyn will be dead in 200 years ... anything else is a really too scary to think about! Any other year that passes until then without IPv6 support are really lost years, if I speak on part of the project.)

[AnsisMalins]

Greetings from the year 2021. I was trying to configure Dynamic DNS on my FreeNAS box and ended up here.

[ThomasCr]

I already use inadyn for a a long time with a ipv6 only host.

my conf looks like this:

verify-address = true
period = 300
forced-update = 86400
allow-ipv6 = true
iface = br0
custom mydom.info {
    ssl              = false
    username         = user
    password         = pass
    ddns-server      = mydom.info
    ddns-path        = "/dyn/?hostname=%h&myip6=%i&noip4"
    hostname         = myhost.mydom.info
    checkip-command  = "/usr/sbin/ip address show scope global dev br0 | grep inet6 | awk '{print $2}' | cut -d/ -f1 | grep -v ^fd | grep 200:200"
}

the important thing is, to set a IPv6 Token. The way to do this depends with your network setup "engine"... I use systemd-networkd with a config file /etc/systemd/network/br0.network like this:

[Match]
Name=br0

[Network]
DHCP=yes
IPv6PrivacyExtensions=yes
IPv6Token=::200:200:200:200

Or for legacy Debian/Ubuntu file /etc/network/interfaces:

iface br0 inet6 auto
      pre-up /sbin/ip token set ::200:200:200:200 dev $IFACE

Or for netplan: canonical/netplan#161
Others may check there: https://serverfault.com/questions/968641/configure-ipv6-address-on-interface-with-static-iid

The only problem I have, that inadyn does not check "only" for ipv6.

Jun 10 07:50:44 myhost inadyn[714]: Failed resolving hostname myhost.mydom.info: No address associated with hostname
Jun 10 07:50:44 myhost inadyn[714]: Update forced for alias myhost.mydom.info, new IP# 2aXX:XXXc:XX:XXXX:200:200:200:200

we need a option to tell inadyn for a dyn host, that this host is ipv4 or ipv6 or ipv4+ipv6, so that it knows what to check.