IPv6 Präfix wird per DynDNS API mit Format error nicht akzeptiert

IPv64.net - Services DynDNS2
,
1

Hallo zusammen,

ich habe das zweifelhafte Glück, nach einem Router-Neustart von meinem Provider zufälig ein Präfix recht weit vorne im Adressbereich meines Providers bekommen zu haben, und dieses lehnt IPv64 mit einem „Format error“ ab. Per Web-UI kann ich es aber problemlos setzen.

Hier mein curl Request, Key fehlt natürlich:

curl -s --connect-timeout 5 'https://ipv64.net/nic/update?key=IRGENDWAS&ip6lanprefix=2100:7111:9cc1::/64'

Antwort:

{"info":"nochg","ipv6prefix":"format error","status":"success","ip":{"ipv6":"<REDACTED>"}}

Meist bekomme ich von meinem Provider eher etwas wie:

2100:7111:9cc1:600::/64

also noch was ungleich „0“ einen Block weiter hinten.

Ist das ein Bug in der API, der zuschlägt, falls man zufällig mal den „nullten Block“ zugeteilt bekommt und damit mehr in :: steckt?

Das gleiche Präfix lässt sich per Web-UI setzen, ohne Fehler.

Viele Grüße,

Oliver

2

Habe gerade neu verbunden und schon wieder so einen Präfix bekommen, bei dem nur drei Blöcke ungleich „0“ sind und der daher dem Muster entspricht:

2a00:6000:9cb1::/64

Workaround scheint leider nur zu sein, das über die Webseite manuell zu setzen — oder kennt jemand einen besseren Weg?

3

Sorry für den erneuten Post, aber ich habe zumindest einen „Würgaround“ für manuelle curl-Updates entwickelt, den ich gerne teile. Wenn man von einem Linux-System mit einer Shell aus updated, kann man einen gültigen Präfix einfach mit:

pad_prefix_ipv64() {
  local full_prefix="$1"
  local addr="${full_prefix%/*}"
  local cidr="${full_prefix##*/}"

  formatted=$(echo "${addr}" | awk -F'::' '{
    split($1, blocks, ":")
    n = ($1 == "") ? 0 : length(blocks)

    if (n == 3) {
      print $1 ":0::" $2
    } else if (n == 2) {
      print $1 ":0:0::" $2
    } else if (n == 1) {
      print $1 ":0:0:0::" $2
    } else if (n == 0) {
      print "0:0:0:0::" $2
    } else {
      print $0
    }
  }')

  echo "${formatted}/${cidr}"
}

vorverdauen. Das macht:

$ pad_prefix_ipv64 2a00:6000:9cb1::/64
2a00:6000:9cb1:0::/64

also padded die Blöcke mit expliziten Nullen. Das geht durch die DYNDNS-API von IPv64.

Das scheint auch der Hack zu sein, den IPv6 Prefix autodetect auf der Webseite nutzt, das gibt den Präfix auch derartig gepadded aus.

Das hilft natürlich nicht bei Clients, die man nicht ändern kann (Fritz!Boxen oder standardkonforme Standalone-Clients) aber ich nutze das bei mir nun in einem Skript auf einem Heimserver, was zusätzlich zur Fritz!Box ein Update macht, falls diese durch den API-Bug versagt.

Ich hoffe, dieser Würgaround kann noch anderen helfen :slight_smile: .

4

Dieses Problem wurde irgendwann innerhalb der letzten 2-3 Wochen in einem Update von ipv64.net gelöst — besten Dank!

Intern scheint der IPv6-Präfix bei einem entsprechenden Update per curl mit :0:: hinten ergänzt zu werden, und dann passt alles.

Der Würgaround sollte also nicht mehr nötig sein :slight_smile: .