IPv6 in freifunk.coburg - routingproblem

[Ulrich Neumann]

Hi Fabian,

Am Sa., 16. Mai 2020 um 18:06 Uhr schrieb Fabian Bläse <fabian at blaese.de>:
> ich konnte es gestern mit einem Windows 10 nicht reproduzieren. Ich würde das aber gern weiter verfolgen, denn wenn die Source Address Selection im Windows kaputt ist, ist das einen Bug Report wert.
Was kommt bei Dir als ergebnis bei Powershell:

find-netroute -remoteipaddress fd43:5602:29bd:4b:0:98de:d0a8:a6fe

oder

Test-NetConnection fd43:5602:29bd:4b:0:98de:d0a8:a6fe -InformationLevel Detailed


> Das Problem ist vermutlich nicht die Route (die war in beiden traceroutes aus der letzten Mail identisch), sondern die Quelladresse, die dein Windows selektiert.

Ja, genau, die Quelladresse ist das Problem.
Ich denke Windows an sich macht es anders als z,B, ubunntu Linux -
aber nicht wirklich falsch.

Inzwischen habe ich hunderte Seiten RFC gelesen, mehrere Linux
Maschinen aufgesetzt, mehrere Windows Systeme neu aufgesetzt von den
ISOS ...

Dreh und Angelpunkt ist wohl der RFC 6724.
In dem RFC wird auf eine modifizierbare Policy Table verwiesen, um die
Quell und Zieladresse zu bestimmen.

ubuntu linux nutzt wohl zur Quelladressbestimmung den im RFC6724
"suggested prefered method" "longest matching prefix" und wählt die
ULA aus.

In Kapitel 10.5. und 10.6 des RFC gehts dann um Multihomed bzw.
multihomed mit ULA Adressen.
Bei Multihomed Hosts ist wohl allein über die Autokonfiguration keine
genaue vorhersage möglich, welche Sourceadresse genutzt wird
(RFC5220).
Darüber hinaus kann jedes Programm auch einen eigene Entscheidung
treffen, ob diese Tabelle überhaupt genutzt wird.

Unter Ubuntu/Debian  Linux gibt es diese Tabelle in der /etc/gai.conf,
(https://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/ch13.html)
Diese kann auch verändert und angepasst werden, doch nach
http://biplane.com.au/blog/?p=122 wird die gar nicht für die
Sourceadresse genutzt, sondern nach dem "longest matching prefix"
gesetzt.

Windows nutzt zur Bestimmung der Zieladresse und Quelladresse diese
policy tabelle.
(https://books.google.de/books?id=u50QAwAAQBAJ&lpg=PA211&dq=ipv6%20precedence&hl=de&pg=PA211#v=onepage&q=ipv6%20precedence&f=false)

find-netroute - gibt bei mir niemals die fd43:: sondern immer die
2a06:: als Sourceadresse an - auch wenn der tracert mal richtig
rausgeht..
Warum tracert oder Ping jeweils "mal eine andere" Quelladresse nutzen?
keine Ahnung - sie verwenden wohl einen eigenen internen Algorythmus
verwenden.

Was heißt das für mich?
Ich gebe auf.
Für mich ist es nicht nachvollziehbar, was richtig ist  und damit kann
ich das Phänomen nicht wirklich eindeutig erklären.
Auch fehlt mir aktuell die Spielwiese und Zeit das nachzustellen und
weiter zu analysieren.
Klar, ich könnte jetzt rumfrickeln bis in der Policy table ein
passender Eintrag drin ist, doch das löst auch nicht die Ursache.
Scheinbar nur ich betroffen bzw. stört sich niemand sonst daran.
Vielleicht raffe ich mich nochmal auf und frage bei heise/iX nochmal nach ...

Was heißt das für fff?
das überlasse ich jedem selbst.


Wichtig ist es denke ich zu sehen, dass sich die OSe bei Multihomed
IPv6 mit ULA und RA aktuell nicht einheitlich verhalten.

newmy