remembering numbers sucks! and they are everywhere! i mean IPv4 with four bytes: ok. but (up to) 16 bytes for IPv6: no way! (and they are even represented in hex!) welcome to the world of tomorrow...
oh wait - there's DNS. why don't use that? fine. any free service provinding DDNS for IPv6 to be used easy?
i basically built it to do:
ssh ipv6-enabled-host.dyndnsix.org
where the target gets IPv6-connectivity through a (registration-free) teredo IPv6-in-IPv4-UDP-tunnel, which even works when both parties are behind NAT. using DynDNSix both can be mobile, while their gateways can change their IPv4 periodically.
to be written (lucky you!)...
updating a record with your current IPv6 is easy. just call a URL from the device you want the name to be assigned to. its IPv6-address will be detected automatically. therefore the update-server update.dyndnsix.org is only available via IPv6 to avoid problems with dual-stack hosts, while this page is also reachable via IPv4. in my examples i will use the name "example". this will assign the DNS name "example.dyndnsix.org" to the IPv6 that requested the URL.
i'm using curl to do the request in my examples. you can exchange it with whatever IPv6-enabled tool you like. even your browser.
there are different ways to use DynDNSix. they differ in the URL.
the most basic version simply updates the DNS record for the given subdomain. this can be done by anyone at any time, so it's perfect for instant assignments that you don't want to use long-term.
update example.dyndnsix.org with your current IPv6:
curl https://update.dyndnsix.org/example
you may choose to provide a secret with your update, which we store. once you've done this for a host, you have to send the same secret with every update-request.
this way you protect your subdomain from unauthorized updates by third-parties.
you cannot change the secret afterwards, so keep it as it is: a secret. we encourage you to use TLS encryption by enforcing the https protocol to talk with our update-server.
the secret can be any (case-sensitive) combination of alpha-numeric characters (A-Z, a-z, 0-9). since you would probably query the update-server from a script, you can make sure that you use some long, random string. e.g. you can generate a 16 character secret using pwgen (linux):
pwgen -s 16 1
with every successful update a new 30 day period begins. within that period your subdomain is protected by your secret. when you don't update for 30 days, the subdomain still resolves your IPv6, but is free to be updated by anybody again.
you can consider this like a light-weight registration. you simply register in-band and every usage is like a registration or every registration is like a regular usage. actually it's not that different (in terms of complexity) from the instant usage.
update example.dyndnsix.org with your current IPv6 protected by secret:
curl https://update.dyndnsix.org/example/secret
you may provide us with an email address to contact you regarding this service. this is really optional, but also requires a secret to be used.
again, this doesn't differ much from the persistent or instant usage described above. you just add your email address to the request.
you can change the email address at any time by issuing an update-request with another one. just make sure subdomain and secret stay the same.
the same way you can delete the email address at any time by updating again and omitting any email address (see persistent usage).
reasons to give email address:
please note, that due to URL-encoding email addresses with containing a plus-sign (+) won't work. i'm really sorry, as i'm a great fan of plussed addresses, but the solution of encoding them is too ugly to be useful...
update example.dyndnsix.org with your current IPv6 protected by secret and your email address mail.example.com:
curl https://update.dyndnsix.org/example/secret/mail@example.com
ask your local ISP for IPv6-connectivity!
you got new ideas, features, improvements? any feedback is appreciated, so just drop me a mail: pille+contact@dyndnsix.org!
last updated: Saturday, 23. October 2010 at 02:20:57 PM UTC [2010-10-23 14:20:57 +0000]