IPv6 dyn-DNS mit dynv6.com, aktionstabelle wählt den falschen präfix

[roell.f]

hallo forum,

nachdem das monatelang funktionierte, wählt die erste aktion in meiner aktionstabelle aus meiner präfix-liste mit hilfe von "%x" nicht mehr den korrekten ersten IPv6-präfix ("::/64") sondern den falschen zweiten präfix ("fdd6:f653:f2a1::/64") aus.

Code: Alles auswählen

cd /Setup/IPv6/Router-Advertisement/Prefix-Options 
del *
#    Interface-Name    Prefix                                       Subnet-ID            Adv.-OnLink  Adv.-Autonomous  PD-Source         Adv.-Pref.-Lifetime  Adv.-Valid-Lifetime  DecrementLifetimes       
#    ===============================================================----------------------------------------------------------------------------------------------------------------------------------------
add "INTRANET" "::/64" {Subnet-ID} "c" {Adv.-OnLink} Yes {Adv.-Autonomous} Yes {PD-Source} "INTERNET" {Adv.-Pref.-Lifetime} 604800 {Adv.-Valid-Lifetime} 2592000 {DecrementLifetimes} No
add "INTRANET" "fdd6:f653:f2a1::/64" {Subnet-ID} "c" {Adv.-OnLink} Yes {Adv.-Autonomous} Yes {PD-Source} "" {Adv.-Pref.-Lifetime} 604800 {Adv.-Valid-Lifetime} 2592000 {DecrementLifetimes} No
add "NET-ADM1C" "fdd6:f653:f2a1::/64" {Subnet-ID} "2" {Adv.-OnLink} Yes {Adv.-Autonomous} Yes {PD-Source} "" {Adv.-Pref.-Lifetime} 604800 {Adv.-Valid-Lifetime} 2592000 {DecrementLifetimes} No
add "NET-PCS1C" "fdd6:f653:f2a1::/64" {Subnet-ID} "10" {Adv.-OnLink} Yes {Adv.-Autonomous} Yes {PD-Source} "" {Adv.-Pref.-Lifetime} 604800 {Adv.-Valid-Lifetime} 2592000 {DecrementLifetimes} No

Code: Alles auswählen

cd /Setup/WAN/Action-Table 
del *
#    Index  Active     Host-Name                                                         Peer              Lock-Time  Condition              Action                                                                                                                                                                                                                                                      Check-For                                           Owner             Routing-Tag  Comment                                                         
#    =======------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
add 1 {Active} Yes {Host-Name} "MyHostname" {Peer} "INTERNET" {Lock-Time} 2160000 {Condition} Establish {Action} "https://dynv6.com/api/update?hostname=%h&token=MyToken&ipv4=%a&ipv6=%z&ipv6prefix=%x" {Check-For} "contains=addresses updated?skipiftrue=2" {Owner} "root" {Routing-Tag} 0 {Comment} ""
add 2 {Active} Yes {Host-Name} "MyHostname" {Peer} "INTERNET" {Lock-Time} 0 {Condition} Establish {Action} "dnscheck:MyHostname" {Check-For} "isequal=%a?skipiftrue=1" {Owner} "root" {Routing-Tag} 0 {Comment} ""
add 3 {Active} Yes {Host-Name} "MyHostname" {Peer} "INTERNET" {Lock-Time} 900 {Condition} Establish {Action} "https://dynv6.com/api/update?hostname=%h&token=MyToken&ipv4=%a&ipv6=%z&ipv6prefix=%x" {Check-For} "contains=addresses updated" {Owner} "root" {Routing-Tag} 0 {Comment} ""
add 4 {Active} Yes {Host-Name} "MyHostname" {Peer} "INTERNET" {Lock-Time} 0 {Condition} Establish {Action} "repeat:300" {Check-For} "" {Owner} "root" {Routing-Tag} 0 {Comment} ""

mir ist bekannt, dass man mit %{xInterfaceName} auch ein interface ansprechen kann, welches nicht "INTRANET" sondern "InterfaceName" heißt. allerdings hilft das nicht weiter, weil die beiden präfixeintrage den gleichen interface-namen besitzen müssen, also nach wie vor nicht über %x unterschieden werden können.

scheinbar gibt es auch nicht so etwas wie %{xInterfaceName}[index], sodaß präfixlisteneinträge auf diese weise unterscheidbar wären.

ebenfalls scheitert:

Code: Alles auswählen

root@lc-1793va-01:/
> cd /Setup/IPv6/Router-Advertisement/Prefix-Options/INTRANET
 Path ambiguous: /Setup/IPv6/Router-Advertisement/Prefix-Options/INTRANET

wie kann ich die probleme "auswahl mit %x" und "Path ambiguous" lösen?

beste grüße
frank

[rotwang]

wie kann ich die probleme "auswahl mit %x" und "Path ambiguous" lösen?

Um auf den zweiten Teil der Frage zu antworten: Die Tabelle hat Namen und Präfix als Index und wenn eine Zeile nicht alleine durch den Namen identifiziert werden kann, muss man halt beides eingeben:

Code: Alles auswählen

root@isg5000:/Setup/IPv6/Router-Advertisement/Prefix-Options
> l

Interface-Name    Prefix                                       Subnet-ID            Adv.-OnLink  Adv.-Autonomous  PD-So 
===============================================================---------------------------------------------------------
INTRANET          ff00::/64                                    1                    Yes          Yes                    
INTRANET          fe00::/64                                    2                    Yes          Yes                    

root@isg5000:/Setup/IPv6/Router-Advertisement/Prefix-Options
> cd intranet
 Path ambiguous: intranet

root@isg5000:/Setup/IPv6/Router-Advertisement/Prefix-Options
> cd intranet ff

root@isg5000:/Setup/IPv6/Router-Advertisement/Prefix-Options/INTRANET  ff00::/64
> 

Was den ersten Teil angeht: Da ist mir keine Möglichkeit bekannt. Das Modul mit der Aktionstabelle hält m.W. pro LAN-Interface-Namen nur einen Präfix nach.

[roell.f]

@rotwang
danke für die lösung zum thema "Path ambiguous".

bezüglich "%x":

Das Modul mit der Aktionstabelle hält m.W. pro LAN-Interface-Namen nur einen Präfix nach.

ich denke das ist schon sehr lange so, nur mit dem unterschied, dass wir uns bis vor kurzem darauf verlassen konnten, dass %x auf den ersten eintrag mit interface-name "INTRANET" zugegriffen hat. dabei kam es nicht auf die reihenfolge an, wie sie lanconfig anzeigte, sondern wie sie in der konfigurationsdatei (*.lcs) stand. da sich die reihenfolge der präfixliste nicht in lanconfig steuern ließ, habe ich die präfixliste in der vergangenheit immer per LCS-skript in den router geladen. damit funktionierte dann das dyn-DNS-update.

IPv6 erlaubt, dass ein interface mehrere präfixe besitzt, jedoch befürchte ich, dass mangels verbreitung solcher fälle dafür im LCOS nichts für deren handling im kontext der aktionstabelle eingebaut wurde.

hm, weiß noch jemand rat?
BG frank

[rotwang]

Davon gehe ich auch aus, und die Frage wäre, wie man die mehreren Präfixe dann eindeutig referenziert, also was man als [index] verwenden würde. Einfach eine Aufzählung der Form 0,1,2,... hilft ja nicht weiter, wenn die Reihenfolge der Übermittlung an die Aktionstabelle undefiniert ist. Dann hat man das gleiche Problem wie mit einem Linux mit mehreren Netzwerkkarten, wo es Zufall sein konnte, was eth0 und eth1 wird...

[roell.f]

2025-04-24 18:10
die versuchshalber installierte firmware 10.72.0203RU3 (2023-04-29) zeigt den gleichen fehler. leider habe ich keine firmware-version mehr, die noch funktionierte.

2025-04-24 18:50
habe neueste firmware 10.90.0221RU3 (2025-04-11) auf dem 1793VA installiert, doch das problem bleibt.

hat jemand noch eine andere idee?

[backslash]

Hi roell.f

warum willst du auf dem LAN ULAs UND öffentliche Adressen ausrollen? Das macht das ganze doch nur unübersichtlich - und vor allem kann es dir passieren, daß es nicht richtig funktioniert, weil u.B. Windows ULAs falsch händelt. Daher solltest du statt ULSs leiber einen Prefix aus dme 2001:db8:: Bereich nehmen - mit dme geth Windows korrekt um. genaueres dazu kann sicherlich Frühstücksdirektor beisteuern...

Zur Aktionstabelle selbst:

Die Aktionstrabelle prüft, ob es ein NPTv6-Mapping gibt und falls ja, nimmt es die Adresse, die sich mappen läßt - das ist bei dir vermutlich die ULA. Die echte öffentliche Adresse wird dabei nicht genommen.
Das war nie anders - zumindest seit es NPTv6 gibt ist das so...

Gruß
Backslash

[roell.f]

hallo backslash,

warum willst du auf dem LAN ULAs UND öffentliche Adressen ausrollen?

zunächst hatte ich einen provider, der mich mit statischen IPv4- und IPv6-adressen (Global Unicast Adresses, GUA) aus dem bereich 2001::/3 versorgte. für Unique Local Addresses (ULA) hatte ich infolge keinen bedarf und habe sie auch nicht verwendet. später bin ich zu einem vertrag gewechselt, der nur dynamische adressen beinhaltet. damit konnte ich aber in meinem LAN den bind9-DNS-server nicht betreiben, weil sich dieser nur mit statischen IPv6-präfixe konfigurieren lässt. also habe ich (wie ich meine regelkonform) dem interface "INTRANET" den ULA-präfix "fdd6:f653:f2a1::/64" hinzugefügt. allerdings hatte der lancom schon damals das problem, dass er bei zwei "INTRANET"-IPv6-präfixen in der aktionstabelle mit %x immer den erste INTRANET-eintrag in der präfixliste heranzog, sich aber die reihenfolge der prefixlisteneinträge mit LANconfig nicht steuern ließ. also habe ich das über LCS-skripte (s.o. im ersten beitrag) bewirkt. das funktionierte über viele wochen bis ich-weiß-nicht-genau-wann.

Das macht das ganze doch nur unübersichtlich - und vor allem kann es dir passieren, daß es nicht richtig funktioniert, weil u.B. Windows ULAs falsch händelt.

ich konnte bislang keine derartigen probleme bei meinen windows- (oder linux-) maschinen beobachten. mit welchen symptomen soll sich das äußern?

Daher solltest du statt ULSs leiber einen Prefix aus dme 2001:db8:: Bereich nehmen - mit dme geth Windows korrekt um. genaueres dazu kann sicherlich Frühstücksdirektor beisteuern...

hm, "2001:db8::" ist eine für dokumentationszwecke reservierte GUA. die zu verwenden halte ich für undienlich, weil nicht regelkonform. aber ich habe es probiert:

Code: Alles auswählen

cd /Setup/IPv6/Router-Advertisement/Prefix-Options 
del *
#    Interface-Name    Prefix                                       Subnet-ID            Adv.-OnLink  Adv.-Autonomous  PD-Source         Adv.-Pref.-Lifetime  Adv.-Valid-Lifetime  DecrementLifetimes       
#    ===============================================================----------------------------------------------------------------------------------------------------------------------------------------
add  "INTRANET"        "::/64"                                     {Subnet-ID}  "c"                 {Adv.-OnLink}  Yes         {Adv.-Autonomous}  Yes             {PD-Source}  "INTERNET"       {Adv.-Pref.-Lifetime}  604800              {Adv.-Valid-Lifetime}  2592000             {DecrementLifetimes}  No
add  "NET-ADM1C"       "fdd6:f653:f2a1::/64"                       {Subnet-ID}  "2"                 {Adv.-OnLink}  Yes         {Adv.-Autonomous}  Yes             {PD-Source}  ""               {Adv.-Pref.-Lifetime}  604800              {Adv.-Valid-Lifetime}  2592000             {DecrementLifetimes}  No
add  "NET-PCS1C"       "fdd6:f653:f2a1::/64"                       {Subnet-ID}  "10"                {Adv.-OnLink}  Yes         {Adv.-Autonomous}  Yes             {PD-Source}  ""               {Adv.-Pref.-Lifetime}  604800              {Adv.-Valid-Lifetime}  2592000             {DecrementLifetimes}  No
add  "INTRANET"        "2001:db8::/64"                             {Subnet-ID}  "c"                 {Adv.-OnLink}  Yes         {Adv.-Autonomous}  Yes             {PD-Source}  ""               {Adv.-Pref.-Lifetime}  604800              {Adv.-Valid-Lifetime}  2592000             {DecrementLifetimes}  No

in dynv6.com kommt dann als IPv-prefix "2001:db8:0:c::" an. das ist leider auch falsch.

erst nach dem entfernen des eintrags { "2001:db8::/64" ... "c"} aus der IPv6-präfixliste liefert die aktionstabelle mit %x den korrekten prefix "2003:c4:8738:f30c::" bei dynv6.com ab.

Zur Aktionstabelle selbst:

Die Aktionstrabelle prüft, ob es ein NPTv6-Mapping gibt und falls ja, nimmt es die Adresse, die sich mappen läßt - das ist bei dir vermutlich die ULA. Die echte öffentliche Adresse wird dabei nicht genommen.
Das war nie anders - zumindest seit es NPTv6 gibt ist das so...

ich benutze kein NPTv6. es ist bei mir nicht konfiguriert.

meines wissens sollen ULAs nicht im web geroutet werden sondern nur GUAs. demanch müsste %x ULAs links liegen lassen und unter den GUAs eine geeignete finden.

ich denke, die gegenwärtige lösung enthält einen konzeptionellen bug, dergestalt, dass der benutzer im LCOS (LANconfig) nicht steueren kann, welcher von mehreren "INTRANET"-IPv6-präfixeinträgen mit %x herangezogen werdens soll. oder?

beste grüße
frank

[Frühstücksdirektor]

Hallo,

nach dem sich Backslash meine Meinung zu dem Thema sich ja quasi gewünscht hat:

Um ULAs würde ich einen weiten Bogen machen. Man hat ULAs leider kaputt-standardisiert: Man hat ein neues RFC geschrieben, dass besagt, dass IPv4 IMMER vor ULAs verwendet werden soll, daraus folgt, dass der IPv6 Loadbalancer und Dual Stack nicht mehr mit ULAs funktioniert, da die Client-OSe immer IPv4 bevorzugen sollen. Passender Artikel dazu hier: https://blog.ipspace.net/2022/05/ipv6-ula-made-useless/

Ich selbst nutze für Low-Budget-Szenarios sogar lieber das Doku-Präfix 2001:db8::/xx hinter NPTv6 (LB, VRRPv3, Backup). Funktioniert einfach nur.
Man sollte grundsätzlich immer feste IPv6-Adressen für ernsthafte Szenarien buchen, die paar Euro sind besser angelegt als sich rumzuärgern. Man rollt nur dieses Präfix aus und umschifft damit die ganzen Probleme mit ULAs und mehreren Präfixen.
Man muss nur das feste Präfix des einen Providers statisch ausrollen und die Backup-Wege zu anderen Leitungen hinter diesem Präfix per NPTv6 mappen, falls das von der Größe möglich ist.

Viele Grüße,
Frühstücksdirektor

[backslash]

Hi roell.f

ich benutze kein NPTv6. es ist bei mir nicht konfiguriert.

Da dürfte der Grund für die Auswahl des "falschen" Prefix sein, daß der (ULA-)Prefix statisch konfiguriert ist und somit als erster verfügbar ist...

das erklärt dann auch

in dynv6.com kommt dann als IPv-prefix "2001:db8:0:c::" an. das ist leider auch falsch.

Dann stellt sich wirklich die Frage, wieso du überhaupt ULAs ausrollst, denn

damit konnte ich aber in meinem LAN den bind9-DNS-server nicht betreiben

kann ich fast nicht glauben - der müßte doch den wechselnden Prefix mitbekommen und seine Datenbank daraufhin anpassen.
aber ich kenne bind nicht wirklich

Aber wenn du nur die ULAs (bzw. wegen des von Frühstüksdirektor beschriebenen Problems 2001:db8:: Adressen) zusammen mit NPTv6 verwendest, dann funktioniert die Aktionstabelle auch...

meines wissens sollen ULAs nicht im web geroutet werden sondern nur GUAs. demanch müsste %x ULAs links liegen lassen und unter den GUAs eine geeignete finden.

woher soll die Aktionstabelle wissen, in welchem Kontext die Adresse verwendet wird. Es ist nunmal legitim in einem (internen) Netz auch ULAs zu verwenden.

Gruß
Backslash

[roell.f]

ich benutze kein NPTv6. es ist bei mir nicht konfiguriert.

Da dürfte der Grund für die Auswahl des "falschen" Prefix sein, daß der (ULA-)Prefix statisch konfiguriert ist und somit als erster verfügbar ist...

hm, "... als erster verfügbar ...", das klingt nach race-conditions und würde bedeuten, das je nach dem wie der umgang mit GUAs und ULAs implementiert ist, mal die GUAs und mal die ULAs zuerst verfügbar würden. ich denke der wert von %x darf nicht von timing-fragen oder vom (programm-) kontrollfluss abhängen.

Dann stellt sich wirklich die Frage, wieso du überhaupt ULAs ausrollst, denn

damit konnte ich aber in meinem LAN den bind9-DNS-server nicht betreiben

kann ich fast nicht glauben - der müßte doch den wechselnden Prefix mitbekommen und seine Datenbank daraufhin anpassen.
aber ich kenne bind nicht wirklich

der ISC-bind-9 kennt genau zwei konfigurationsvarianten:

1. statisch
   dabei stehen alle rekords in textdateien. infolge müssen unter anderem die IPv6-adressen bestehend aus präfix und interface-identifier in beiden teilen feststehen. entweder kommt der präfix in dieser variante von einer statischen GUA oder (wie in meinem fall) von einer statischen ULA.
2. dynamisch
   dabei bezieht der der ISC-bind-9 seine adressen vom ISC-DHCPv6. letzter lässt sich nur über textdateien mit statisch eingetragenen IPv6-präfixen konfigurieren. diese präfix stammen genauso wie in variante a) entweder von einer statischen GUA oder von einer statischen ULA.

Aber wenn du nur die ULAs (bzw. wegen des von Frühstüksdirektor beschriebenen Problems 2001:db8:: Adressen) zusammen mit NPTv6 verwendest, dann funktioniert die Aktionstabelle auch...

die NPTv6-funktionlität benötige ich nicht. sie nur deshalb zu konfigurieren, damit die aktionstabelle funktioniert, ergibt in meinen augen keinen sinn.

Es ist nunmal legitim in einem (internen) Netz auch ULAs zu verwenden.

ja, es ist legitim in einem internen netz ULAs zu verwenden. aber es ergibt keinen sinn sie per %x einem dyndns-server zu übermitteln, da kein client dieses servers mit einer ULA einen host im WAN erreichen kann, denn Unique-Local-Adresses (ULAs) werden im WAN nicht geroutet.

die bis hierher behandelte GUA-/ULA-/NPTv6-thematik beschreibt nur das umfeld des problems. ich halte sie aber nicht für den kern des problems.

der kern kommt m.E. ab hier:

woher soll die Aktionstabelle wissen, in welchem Kontext die Adresse verwendet wird?

vom benutzer!

er spezifiziert z.B. im LANconfig, welcher von den IPv6-präfixe herangezogen werden soll. entweder

1. vergibt man jedem eintrag in der präfixliste einen eindeutigen namen (z.B, "MyPrefixNameA") und greift darüber und eckigen klammern z.B. mittels

   Code: Alles auswählen

   %{x[MyPrefixNameA]}

   zu oder
2. man schafft im LANconfig die möglichkeit die reihenfolge der IPv6-prefixlisteneinträge zu steueren (Up-/Down-Knopf) und greift über einen index z.B. mittels

   Code: Alles auswählen

   %{x,INTRANET[1]}

   zu.

ich finde lösungsvariante a) robuster.

was meint ihr?

beste grüße
frank

[backslash]

Hi roell.f

hm, "... als erster verfügbar ...", das klingt nach race-conditions und würde bedeuten, das je nach dem wie der umgang mit GUAs und ULAs implementiert ist, mal die GUAs und mal die ULAs zuerst verfügbar würden. ich denke der wert von %x darf nicht von timing-fragen oder vom (programm-) kontrollfluss abhängen.

ich kann dazu nur rotwang zitieren:

Das Modul mit der Aktionstabelle hält m.W. pro LAN-Interface-Namen nur einen Präfix nach.

und zwar den Ersten, der "aktiv" wird...

die NPTv6-funktionlität benötige ich nicht. sie nur deshalb zu konfigurieren, damit die aktionstabelle funktioniert, ergibt in meinen augen keinen sinn.

nun ja, du nutzt ja auch die ULAs, nur damit dein bind vernünftig arbeitet. Was spricht dann dagegen, für die ULAs einen NTPv6-Eintrag zu erstellen.
Deine internen Hosts werden die ULAs von sich aus nicht nutzen, da sie ja auch eine öffentliche Adresse haben. Aber sobald du von aussen auf einen Server (per dyndns-namen) zugreifen willst, wird der Zugriff per NPTv6 gemappt.

der kern kommt m.E. ab hier:

woher soll die Aktionstabelle wissen, in welchem Kontext die Adresse verwendet wird?

vom benutzer!

er spezifiziert z.B. im LANconfig, welcher von den IPv6-präfixe herangezogen werden soll. entweder

vergibt man jedem eintrag in der präfixliste einen eindeutigen namen (z.B, "MyPrefixNameA") und greift darüber und eckigen klammern z.B. mittels

Code: Alles auswählen

%{x[MyPrefixNameA]}

zu oder
man schafft im LANconfig die möglichkeit die reihenfolge der IPv6-prefixlisteneinträge zu steueren (Up-/Down-Knopf) und greift über einen index z.B. mittels

Code: Alles auswählen

%{x,INTRANET[1]}

zu.

das wäre eine Erweiterung der Aktionstabellle bzw. der IPv6-Konfiguration und hilft dir momentan also nicht weiter...

Gruß
Backslash

[roell.f]

hallo Frühstücksdirektor,
hallo backslash,

in dieser antwort soll es nur um das thema "2001:db8 statt ULA" gehen. bezüglich "aktionstabelle" melde ich mich später.

Um ULAs würde ich einen weiten Bogen machen. Man hat ULAs leider kaputt-standardisiert: ...

Ich selbst nutze für Low-Budget-Szenarios sogar lieber das Doku-Präfix 2001:db8::/xx hinter NPTv6 (LB, VRRPv3, Backup). Funktioniert einfach nur.

Man sollte grundsätzlich immer feste IPv6-Adressen für ernsthafte Szenarien buchen, die paar Euro sind besser angelegt als sich rumzuärgern.

da ich auf die schnelle nicht zu einem provider mit business-vertrag (statische IPv4 und IPv6) wechseln kann, bin ich euerem rat gefolgt und habe in der IPv6-präfixliste "fdd6:f653:f2a1::/64" (ULA) durch "2001:db8:f2a1::64" (dokumentations-GUA) ersetzt:

Code: Alles auswählen

cd /Setup/IPv6/Router-Advertisement/Prefix-Options 
del *
#    Interface-Name    Prefix                                       Subnet-ID            Adv.-OnLink  Adv.-Autonomous  PD-Source         Adv.-Pref.-Lifetime  Adv.-Valid-Lifetime  DecrementLifetimes       
#    ===============================================================----------------------------------------------------------------------------------------------------------------------------------------
add "INTRANET" "::/64" {Subnet-ID} "c" {Adv.-OnLink} Yes {Adv.-Autonomous} Yes {PD-Source} "INTERNET" {Adv.-Pref.-Lifetime} 604800 {Adv.-Valid-Lifetime} 2592000 {DecrementLifetimes} No
add "INTRANET" "2001:db8:f2a1::/64" {Subnet-ID} "c" {Adv.-OnLink} Yes {Adv.-Autonomous} Yes {PD-Source} "" {Adv.-Pref.-Lifetime} 604800 {Adv.-Valid-Lifetime} 2592000 {DecrementLifetimes} No
add "NET-ADM1C" "2001:db8:f2a1::/64" {Subnet-ID} "2" {Adv.-OnLink} Yes {Adv.-Autonomous} Yes {PD-Source} "" {Adv.-Pref.-Lifetime} 604800 {Adv.-Valid-Lifetime} 2592000 {DecrementLifetimes} No
add "NET-PCS1C" "2001:db8:f2a1::/64" {Subnet-ID} "10" {Adv.-OnLink} Yes {Adv.-Autonomous} Yes {PD-Source} "" {Adv.-Pref.-Lifetime} 604800 {Adv.-Valid-Lifetime} 2592000 {DecrementLifetimes} No

und anschließend mein gesamtes LAN umgestellt. das war eine menge arbeit, wurde aber mit erheblich besserer latenz belohnt. vor der umstellung legten meine maschinen gerne eine halbe gedenksekunde ein, bevor eine applikation startete bzw. bevor sich im microsoft-datei-explorer ein neuer ordner für die anzeige seines inhalts öffnete. insofern war meine aussage falsch:

ich konnte bislang keine derartigen probleme bei meinen windows- (oder linux-) maschinen beobachten.

und auf meine eigene frage:

mit welchen symptomen soll sich das [ULA-problem] äußern?

lautet die anwort: "nicht an geringerer bandbreite im LAN sondern an erhöhter latenz (s.o. 'gedenksekunde')."

herzlichen dank für euren hinweis.

viele grüße und bis später
frank

[roell.f]

hallo backslash,

lasse uns zurückkommen zum thema "aktionstabelle":

[...] Was spricht dann dagegen, für die ULAs einen NTPv6-Eintrag zu erstellen.
Deine internen Hosts werden die ULAs von sich aus nicht nutzen, da sie ja auch eine öffentliche Adresse haben. Aber sobald du von aussen auf einen Server (per dyndns-namen) zugreifen willst, wird der Zugriff per NPTv6 gemappt.

ok, ich habe die beschreibung unter https://knowledgebase.lancom-systems.de ... d=78479773 verwendet mit folgenden einstellungen:

Code: Alles auswählen

cd /Setup/IPv6/Router-Advertisement/Prefix-Options 
del *
#    Interface-Name    Prefix                                       Subnet-ID            Adv.-OnLink  Adv.-Autonomous  PD-Source         Adv.-Pref.-Lifetime  Adv.-Valid-Lifetime  DecrementLifetimes       
#    ===============================================================----------------------------------------------------------------------------------------------------------------------------------------
add "INTRANET" "2001:db8:f2a1::/64" {Subnet-ID} "c" {Adv.-OnLink} Yes {Adv.-Autonomous} Yes {PD-Source} "" {Adv.-Pref.-Lifetime} 604800 {Adv.-Valid-Lifetime} 2592000 {DecrementLifetimes} No

bzw.

Code: Alles auswählen

cd /Setup/IPv6/Firewall/NPTV6 
del *
#    Interface-Name    source-prefix                                mapped-prefix                              
#    ===============================================================-------------------------------------------
add "INTERNET" "2001:db8:f2a1::/64" {mapped-prefix} "::/64"

nach do Other/Cold-Boot zeigt das dynv6-portal IPv6 Prefix: 2001:db8:f2a1:c:: an.

fehlt noch etwas oder ist falsch konfiguriert?

beste grüße
frank