Hofheim Hood, ipv6 funktioniert, leider nur teilweise, z.b. windowsupdates nicht funktionierend wenn dualstack eingeschaltet

Fabian Bläse fabian at blaese.de
So Dez 29 22:57:01 CET 2019



On 29.12.19 22:40, Andreas Bittner FFF wrote:
> On 29.12.2019 22:35, Fabian Bläse wrote:
>> Schwierig.. Du bekommst halt unerwartet keine Antwort vom Server. 
>> Wenn Ping geht, aber ein Dienst, der mit größeren Daten hantiert
>> nicht funktioniert und nur ewig lädt, ist die Wahrscheinlichkeit
>> groß, dass es sich um ein Problem in dieser Richtung handelt. Die
>> eigentliche Problematik ist nur auf dem Router sichtbar, auf dem sich
>> die MTU auf dem Weg vom einen zum anderen Interface ändert.
>>
>> Du möchtest gar nicht wissen, wie kaputt PMTUD bei IPv4 ist. Dort ist
>> es so schlimm, dass viele Webseiten ohne MSS Clamping nicht benutzbar
>> sind. So nicht benutzbar, dass eigentlich alles IPv4 Exits im
>> Freifunk MSS Clamping (oder etwas vergleichbares) machen. Das Problem
>> sind vermutlich fast immer zu restriktive Firewalls, ICMP Pakete sind
>> ja böse.
>>
>> Weil die Frage jetzt gleich kommen wird: Ja, man kann auch bei IPv6
>> in der MSS rumpfuschen. Das ist aber eigentlich nicht Aufgabe eines
>> Routers und funktioniert natürlich auch nur für TCP. Bei IPv6 haben
>> die allermeisten PMTUD im Griff, daher ist es (jedenfalls bei mir)
>> eine idealistische Entscheidung, bei IPv6 kein MSS Clamping zu
>> machen.
>>
>> IPv4 hat hier aber noch eine Besonderheit: Dort war ursprünglich
>> vorgesehen, dass Router auf dem Weg Pakete fragmentieren. Später
>> wurde dann das "Don't Fragment" Bit ergänzt. Ist dieses gesetzt,
>> verwerfen Router das Paket stattdessen und senden passende ICMP
>> Fehler. Das "Don't Fragment"-Bit ist mittlerweile so gut wie überall
>> default, die Firewalls berücksichtigen das aber häufig nicht. Selbst
>> größere Buden (oder vielleicht gerade die? ..) haben das nicht im
>> Griff. Die Webseiten "ui.com" (Routerhersteller, ziemlich peinlich..)
>> und "telekom.de" (Extra-Peinlich, da sie ja selbst ausschließlich
>> Anschlüsse mit verringerter MTU im Angebot haben..) haben das beide
>> nicht im Griff.
>> Mehr Infos: https://wiki.freifunk-franken.de/w/MTU
> 
> 
> Ich habe noch eine recht passende Analyse auch spezielle fuer die
> Windowsupdates Server mit MTU gefunden:
> 
> <https://ldx.ca/notes/mtu-mss-ipv6.html>
> 
> Dort ist auch von z.B. RFC1981 die die Rede, was mich aber wundert ist,
> dass das wording dort SHOULD lautet, was dann die Frage aufwirft, wie
> Teilnehmer die kein SHOULD befolgen dann IPV6 Konnektivitaet end-to-end
> sicherstellen sollen :(
Ein Absatz später:
   Nodes not implementing Path MTU Discovery must use the IPv6 minimum
   link MTU defined in [RFC8200] as the maximum packet size.  In most
   cases, this will result in the use of smaller packets than necessary,
   because most paths have a PMTU greater than the IPv6 minimum link
   MTU.  A node sending packets much smaller than the Path MTU allows is
   wasting network resources and probably getting suboptimal throughput.

   (rfc8201, steht aber auch im obsoleten rfc1981 drin)

Gruß
Fabian

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://lists.freifunk.net/pipermail/franken-freifunk.net/attachments/20191229/4d1a5b33/attachment.sig>


Mehr Informationen über die Mailingliste franken