MTU-Wert 1500 auf Netzwerkkarte macht nur 1492?

[Schnäppchenjäger]

Habe den Test per cmd gemacht und herausgefunden, dass meine MTU auf 1500 liegen sollte (das ist der kleinste Wert+28, wo die Pakete nicht fragmentiert werden).
War auch sowieso voreingestellt, soweit sogut.
(MTU)

Nun sehe ich aber in meinem Ethernetstatus folgendes:
(Netzwerkeigenschaften)

Wieso steht da 1492? Ist das der maximale oder optimale Wert des Ethernetadapters?
Gelten die gesetzten 1500 überhaupt? Wieso kann ich nirgends den MTU-Wert meines bescheuerten Spedport Routers sehen? ;D

[qiller]

Hm, also bei mir steht überall 1500 und ich hab genau dieselbe NIC bei mir verbaut. Ist das vlt nen gemessener/berechneter Wert der gegenüber einem Internetserver ermittelt wird? Dann würd ich mal tippen, du hast ne DSL-Leitung, wo ja 8 Bytes (1500-8) reserviert werden. Ich hab z.B. nen Kabelanschluss.

Edit: Macht irgendwie trotzdem kein Sinn, die MTU einer NIC im LAN sollte 1500 sein, egal ob die dann an nem Router mit DSL-Anschluss geht. Nur wenn du direkt die NIC an nem DSL-Modem (also kein Router) verbindest und du dich in Windows bei deinem Provider einwählst, sollte es auf 1492 stehen.

[Schnäppchenjäger]

Hm, also bei mir steht überall 1500 und ich hab genau dieselbe NIC bei mir verbaut. Ist das vlt nen gemessener/berechneter Wert der gegenüber einem Internetserver ermittelt wird? Dann würd ich mal tippen, du hast ne DSL-Leitung, wo ja 8 Bytes (1500-8) reserviert werden. Ich hab z.B. nen Kabelanschluss.

Edit: Macht irgendwie trotzdem kein Sinn, die MTU einer NIC im LAN sollte 1500 sein, egal ob die dann an nem Router mit DSL-Anschluss geht. Nur wenn du direkt die NIC an nem DSL-Modem (also kein Router) verbindest und du dich in Windows bei deinem Provider einwählst, sollte es auf 1492 stehen.
Ist 'ne Glasfaserleitung, externes Modem und dann der Speedport router halt. habe gerade im Hidden Menü des Routers nachgeschaut, da steht auch 1492, auf Windows ist der Wert auf 1500 gestellt, so wie es sein sollte, aber scheinbar hat der Router das auf 1492 gesetzt?

Zusatzinfo:
Schaut mal den Wert bei MTU an bei Ipv4 (1500) und dann bei Ipv6 (1492).
Ist das normal dass das unterschiedliche Werte sind?

[Lowkey]

Es gibt eine Möglichkeit den idealen Wert zu bestimmen. Die Anleitung hatte ich mal. Der Wert liegt weiter unter 1500.

[Schnäppchenjäger]

Es gibt eine Möglichkeit den idealen Wert zu bestimmen. Die Anleitung hatte ich mal. Der Wert liegt weiter unter 1500.
Nicht wirklich, bei mir lag er bei 1472, ab 1473 fragmentiert er. Man muss ja immer 28 dazurechnen, also kamen 1500 raus. Das ist die Einstellung in Windows, aber der Netzwerkadapter zeigt halt "nur" 1492 an und der Router ist auf 1500 bei ipv4 gestellt und 1492 bei ip6. wenn ich das richtig deute.

Router ist Speedport W724v Typ B.

[lumines]

Kommt auch drauf an, wie du dich einwählst. Wikipedia sagt, dass bei PPPoE die MTU sogar ≤ 1492 sein muss. Per Ethernet sind 1500 normal: https://de.wikipedia.org/wiki/Maximum_Transmission_Unit

Ehrlich gesagt kommen mir die 1500 bei IPv4 seltsamer vor als die 1492 bei IPv6. Eventuell wird IPv4 bei dir irgendwie in IPv6 gekapselt und deshalb kann die MTU 1500 Byte groß sein?

Der Header bei IPv6 ist auch etwas größer. Eventuell erklärt das den Unterschied. Trotzdem interessant, dass du 1500 Bytes als MTU per Glasfaser fahren kannst. Wusste gar nicht, dass es die gleiche MTU wie normales Ethernet hat.

[Schnäppchenjäger]

Kommt auch drauf an, wie du dich einwählst. Wikipedia sagt, dass bei PPPoE die MTU sogar ≤ 1492 sein muss. Per Ethernet sind 1500 normal: https://de.wikipedia.org/wiki/Maximum_Transmission_Unit

Ehrlich gesagt kommen mir die 1500 bei IPv4 seltsamer vor als die 1492 bei IPv6. Eventuell wird IPv4 bei dir irgendwie in IPv6 gekapselt und deshalb kann die MTU 1500 Byte groß sein?
Ich habe beides aktiviert, Ipv4 und Ipv6 in den Adaptereinstellungen. Teredotunneling ist auch automatisch aktiv, sollte das deaktiviert sein?

Aus dem FAQ der Fritz!Box:
Die Maximum Transmission Unit (MTU) beschreibt die maximale Größe der Nutzdaten, die in einem einzelnen Datenpaket übertragen werden können. Für DSL-Verbindungen, die die FRITZ!Box mittels PPPoE-Protokoll (Point to Point Protocol over Ethernet) herstellt, steht eine maximale MTU von 1492 Byte zur Verfügung. Bei Betrieb der FRITZ!Box am Glasfaser- oder Kabelanschluss steht eine maximale MTU von 1500 Byte zur Verfügung. Die maximale MTU wird bei Einsatz zusätzlicher Protokolle durch den Internetanbieter reduziert.

[qiller]

Ist 'ne Glasfaserleitung, externes Modem und dann der Speedport router halt. habe gerade im Hidden Menü des Routers nachgeschaut, da steht auch 1492, auf Windows ist der Wert auf 1500 gestellt, so wie es sein sollte, aber scheinbar hat der Router das auf 1492 gesetzt?

Zusatzinfo:
Schaut mal den Wert bei MTU an bei Ipv4 (1500) und dann bei Ipv6 (1492).
Ist das normal dass das unterschiedliche Werte sind?

Ahh, Windows zeigt dir den Wert für IPv6 an. Da kann ich leider nicht mitreden, hab noch kein IPv6. Aber es sieht so aus, als ob die MTU bei IPv6 dynamisch vom Router festgelegt werden kann bzw. ausgehandelt wird (Path MTU Discovery?).

Wenn ich die Wiki-Einträge richtig verstehe, wird bei IPv6 per Path MTU Discovery die MTU dynamisch ermittelt. Die 1492 wird dann wohl nur die MTU für den Weg von deinem Rechner zum Speedport darstellen. Das heißt nicht, dass derselbe Wert auch für die Verbindung zu ipv6.google.com benutzt wird. Benutzt wird letztendlich die kleinste MTU welche für jedes Teilstück ermittelt wurde. Ich könnte mir z.B. gut vorstellen, dass bei Nutzung von Proxy-Server, VPN-Verbindungen oder Tor-Netzwerk sich die MTU sogar ändert, obwohl man dieselbe Quelle und dasselbe Ziel nutzt, halt nur auf nem anderen Weg.

[lumines]

Habe ich komplett übersehen, dass es im Screenshot vom Router um die Verbindung zwischen Rechner und Router geht. Ok, da ergibt das natürlich komplett Sinn. Wenn 1500 Bytes die normale MTU für Ethernet ist und IPv6 einen größeren Overhead durch den größeren Header hat, dann kommt das genau hin. Da gibt es ja nichts zwischen Rechner und Router, was irgendwie für eine geringere MTU sorgen könnte.

Interessanter wäre natürlich die jeweilige MTU vom Rechner ins Internet (mit welchem Protokoll auch immer).

IPv6 sollte das über ICMPv6 über die jeweiligen Fehlercodes aber auch selbst alles einstellen, wie qiller das schon gesagt hat. ICMPv6 ist so ein integraler Bestandteil von IPv6, dass bestimmte Codes auch nirgendwo geblockt werden dürfen.

EDIT: Kann man auch hier nachlesen: https://tools.ietf.org/html/rfc8201

Interessante Details:

IPv6 nodes should implement Path MTU Discovery in order to discover and take advantage of paths with PMTU greater than the IPv6 minimum link MTU [RFC8200]. A minimal IPv6 implementation (e.g., in a boot ROM) may choose to omit implementation of Path MTU Discovery.

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.

Path MTU Discovery kann also benutzt werden, muss aber nicht. Wenn nicht, fällt es auf die minimale MTU von IPv6 zurück, was wohl 1280 Byte ist.

Nodes implementing Path MTU Discovery and sending packets larger than the IPv6 minimum link MTU are susceptible to problematic connectivity if ICMPv6 [ICMPv6] messages are blocked or not transmitted. For example, this will result in connections that complete the TCP three-way handshake correctly but then hang when data is transferred. This state is referred to as a black-hole connection [RFC2923]. Path MTU Discovery relies on ICMPv6 Packet Too Big (PTB) to determine the MTU of the path.


Wenn da etwas nicht richtig funktioniert, hat man also entweder durch die minimale IPv6-MTU einen sehr viel geringeren Durchsatz oder hängende Verbindungen. Wenn die Verbindung grundsätzlich Daten überträgt und die MTU nicht die 1280 Bytes sind, ist alles in Ordnung.

Unter 5.1 Layering (https://tools.ietf.org/html/rfc8201#section-5.1) kann man das nachlesen, was qiller da schon angedeutet hat und wie das für Protokolle über IPv6 mit der MTU umgesetzt werden sollte.

Sehr wahrscheinlich wirst du dir darum keine Gedanken machen müssen, wenn alles funktioniert.

[Schnäppchenjäger]

Haber gerade mit der Telekom telefoniert und die meinten, ich kann ipv6 auch einfach ausschalten, die IPv6 IP wird zwar vergeben, aber nicht wirklich benutzt, das wird über Ipv4 getunnelt oder sowas.
Und ja, Glasfaser hat wohl den Standardwert bei der MTU auf 1500, genauso wie Ethernet.

Perfekt, jetzt müsst man nur noch wissen, wieso der Gigabit Intel Controller auf dem Mainboard nur max. 1492 anzeigt :eek:

Btw: es ist ja nicht so, dass ich Probleme hätte oder hatte, aber diese Settings haben mich schon mal zum Nachdenken angeregt und ob eventuell etwas falsch konfiguriert ist.

[qiller]

Also wenn du IPv6 abschaltest, sollte ja nur noch der MTU-Wert von IPv4 angezeigt werden, dann müsste er eigt. wieder 1500 anzeigen.

[Daredevil]

Mit den MTU Werten haben wir doch vor 15 Jahren bei CS 1.5 rumgespielt, damit auf Aztec auf Entfernung viel besser reingeht und der ping nicht so schwankt. :D

Ist das heute immer noch in Mode?
Das ganze hat ja dann irgendwann aufgehört, als man Router benutzt hat, weil dort nicht viel zu modden war.

[lumines]

Haber gerade mit der Telekom telefoniert und die meinten, ich kann ipv6 auch einfach ausschalten, die IPv6 IP wird zwar vergeben, aber nicht wirklich benutzt, das wird über Ipv4 getunnelt oder sowas.

Also bei der Telekom hat man meistens Dual-Stack. Dein Betriebssystem wird da je nach Adresse auf der Gegenseite entweder IPv4 oder IPv6 benutzen. Eventuell wird IPv6 leicht bevorzugt. Durch das Happy-Eyeballs-Protokoll (https://en.wikipedia.org/wiki/Happy_Eyeballs) hat man mit Dual-Stack aber eigentlich nur Vorteile. Man muss schon sehr lange im Sondermüll suchen, um Geräte zu finden, die kein Happy Eyeballs können. Die unterstützen dann aber auch meistens nur entweder IPv6 oder IPv4, aber nicht beides. Habe da so einen Sony-Fernseher, bei dem das so ist. Keine Ahnung, wer sich das ausgedacht hat.

Eher wird auch IPv4 in IPv6 gekapselt, aber das sollte bei der Telekom nicht der Fall sein. Würdest du bei einem Kabelanbieter am Router IPv6 deaktivieren, hättest du z.B. automatisch auch kein IPv4 mehr. Die setzen praktisch alle nur noch primär auf IPv6.

Es gibt Teredo als Protokoll, wenn man nur IPv4 hat. Die Xbox kann z.B. IPv6 über IPv4 tunneln. Teredo ist aber nur eine Stütze für IPv4-only-Anschlüsse.

Hier kannst du gucken, ob du wirklich IPv6 an deinem Anschluss hast: http://ipv6-test.com/

Btw: es ist ja nicht so, dass ich Probleme hätte oder hatte, aber diese Settings haben mich schon mal zum Nachdenken angeregt und ob eventuell etwas falsch konfiguriert ist.

Wenn es keine offensichtlichen Probleme gibt, kannst du dir ziemlich sicher sein, dass alles richtig konfiguriert ist. Wäre auch seltsam, wenn die Telekom ihre Speedports gerade bei IPv6 nicht richtig konfigurieren würde. Bei Windows kann man das auch ausschließen, wenn man keine manuellen Eingriffe vorgenommen hat.

Solche Sachen sind schon ziemlich fundamental im TCP/IP-Stack. Wenn sich das nicht selbst einstellen würde, dann würde ich die entsprechenden Geräte / Software eher dem Sondermüll zuführen als nach der falschen Konfiguration zu suchen. Mit IPv6 muss man da schon grobe Fehler machen wie z.B. bestimmte essentielle ICMPv6-Codes zu blocken.

Mit den MTU Werten haben wir doch vor 15 Jahren bei CS 1.5 rumgespielt, damit auf Aztec auf Entfernung viel besser reingeht und der ping nicht so schwankt. :D

Ist das heute immer noch in Mode?
Das ganze hat ja dann irgendwann aufgehört, als man Router benutzt hat, weil dort nicht viel zu modden war.

Eigentlich nicht. Wer heute an einem Router Path MTU Discovery irgendwie blockiert, der gehört geteert und gefedert. Ich bin mit MTU-Problemen aber auch noch nie in Kontakt gekommen, daher kenne ich das nur vom Hören-Sagen. It just werks.

[qiller]

@schnäppchenjäger: du könntest ja mal mit ping bisschen rumtesten und gucken, wann er mit dem df-flag noch pingt, und wann nicht mehr.

mit 1500 MTU:

IPv4:
ping www.google.com -4 -f -l 1472

Die Länge für den maximalen Ping-Sendepuffer berechnet sich so: 1500[MTU]-20[IPv4]-8[ICMPv4]=1472.
1473 sollte eine Fragmentmeldung ergeben, wenn die MTU 1500 ist.

IPv6:

ping ipv6.google.de -6 -l 1452

Bei IPv6 sieht es folgendermaßen aus: 1500[MTU]-40[IPv6]-8[ICMPv6]=1452. Problem beim Ping mit IPv6: Man kann kein DF-Flag mehr setzen (-f), sondern müsste jetzt per Wireshark die ICMPv6-Anworten auf "packet too big"-Meldungen durchforsten, wenn Path MTU Discovery unterstützt wird. Es gibt aber auch nen netsh-Befehl, der einem die ausgehandelten und im Cache befindlichen PMTU-Werte für jedes Ziel anzeigen kann:

netsh interface ipv6 show destinationcache interface="Ethernet"

Hier steht das ganze etwas ausführlicher:
https://njetwork.wordpress.com/2014/01/17/ping6-and-fragments/

Auf jeden Fall könntest du so herausbekommen, ob die MTU für den IPv6-Stack zu deinem Router tatsächlich 1492 beträgt.

Edit: Ich seh gerade in deinem Screenshot im ersten Post, dass der Router wohl gar keine IPv6-Adressen in deinem LAN per DHCPv6 vergibt (Unique Local Unicast: fc00:: ), sondern deine NIC in Windows einfach auf Autoconfig steht (Link Local Unicast: fe80::1). Soweit ich weiß, werden die Autoconfig-IP-Bereiche doch gar nicht ins Internet weitergeroutet, oder schickt Windows die IPv6-Pakete dann trotzdem einfach zum Router und der macht dann ne Art NAT? Wenn nicht, dürfte natives IPv6 beim TE gar nicht funktionieren (sondern höchstens Teredo-Tunnel o.ä.).

Edit2: Ok, hat sich wohl geklärt, der Speedport benutzt einfach den fe80::-Bereich für die Adress-Vergabe. Ka ob das jetzt standardkonform ist.

[Lowkey]

Bei mir steht nur, dass der 100Mbit Modus der Fritzbox als Stromsparmodus gilt. Die 1000Mbit braucht wohl mehr Strom. Mit der 50Mbit Leitung sind also 100Mbit Lan die bessere Wahl wie mir scheint.

Man kann natürlich noch sämtliche Protokolle in der Windows Netzwerk Umgebung deaktivieren und im Treibermenu die ganzen Fehlerkorrekturen. Aber vom MTU Tuning halte ich nichts mehr.

[Schnäppchenjäger]

@schnäppchenjäger: du könntest ja mal mit ping bisschen rumtesten und gucken, wann er mit dem df-flag noch pingt, und wann nicht mehr.

mit 1500 MTU:

IPv4:
ping www.google.com -4 -f -l 1472

Die Länge für den maximalen Ping-Sendepuffer berechnet sich so: 1500[MTU]-20[IPv4]-8[ICMPv4]=1472.
1473 sollte eine Fragmentmeldung ergeben, wenn die MTU 1500 ist.
Jap, so war es auch. Ab 1473 logischerweise fragmentiert. Aber jetzt nach dem Deaktivieren von Ipv6 und Konsorten fragmentiert er erst ab 1465, 1464 ist unfragmentiert, entspräche als 1492? Wieso hat sich das geändert, nur weil ich jetzt nur noch Ipv4 benutze? :eek:
Im LAN Interface des Routers steht bei Ipv4 MTU 1500, bei WAN 1492 :confused:

Also wenn du IPv6 abschaltest, sollte ja nur noch der MTU-Wert von IPv4 angezeigt werden, dann müsste er eigt. wieder 1500 anzeigen.
Genau :)

Also bei der Telekom hat man meistens Dual-Stack. Dein Betriebssystem wird da je nach Adresse auf der Gegenseite entweder IPv4 oder IPv6 benutzen. Eventuell wird IPv6 leicht bevorzugt. Durch das Happy-Eyeballs-Protokoll (https://en.wikipedia.org/wiki/Happy_Eyeballs) hat man mit Dual-Stack aber eigentlich nur Vorteile. Man muss schon sehr lange im Sondermüll suchen, um Geräte zu finden, die kein Happy Eyeballs können.

Eher wird auch IPv4 in IPv6 gekapselt, aber das sollte bei der Telekom nicht der Fall sein. Würdest du bei einem Kabelanbieter am Router IPv6 deaktivieren, hättest du z.B. automatisch auch kein IPv4 mehr. Die setzen praktisch alle nur noch primär auf IPv6.

Es gibt Teredo als Protokoll, wenn man nur IPv4 hat. Die Xbox kann z.B. IPv6 über IPv4 tunneln. Teredo ist aber nur eine Stütze für IPv4-only-Anschlüsse.

Hier kannst du gucken, ob du wirklich IPv6 an deinem Anschluss hast: http://ipv6-test.com/.
Ja, die Telekom hat Dualstack. IPv6 adressen werden über 4 gekapselt (oder so was in der Art) meinte die Frau am Telefon, also nativ IPv6 wird da gar nicht bentuzt.
Auf der http://ipv6-test.com/

Seite hatte ich 10/10 Punkte, alles perfekt, nachdem ich dann alles deaktiviert habe natürlich 0/10^^

Habe das folgendermaßen deaktiviert: Haken raus bei Adaptereinstelluingen zu Ipv6, dann folgende Befehle in cmd:
"netsh interface ipv6 6to4 set state state=disabled undoonstop=disabled"

"netsh interface teredo set state disabled"

"netsh interface ipv6 isatap set state state=disabled"

den IP Helper Service beendet und deaktiviert

und DisabledComponents in der Registry mit dem richtigen WErt 255, damit der 5 Sekunden Delay beim Booten nicht auftritt :cool:

Das einzige was mich verwundert, ist dass die Pakete vorher erst bei 1472 unfragmentiert waren, nun bei 1464....:frown:

edit: Noch ein Test: wenn ich ping -f -l xxxx 192.168.2.1 (xxxx steht für den MTU-Wert) eingebe, fragmentiert er erst ab 1473, also ab 1472 ist es unfragmentiert. Wenn ich aber den anderen Befehl ausführe(Ping google.de -f -l 1464), ist es erst ab 1464 unfragmentiert.

[qiller]

Was pingst du denn an? Die interne Router-IP? Oder ein Server im Internet? Also den Router solltest du eigt. ganz normal mit 1500 (-l 1472) anpingen können, da ist nämlich der Internetanschluss vollkommen egal.

Pingst du allerdings nen Server im Internet an, dann hast du wohl doch eine MTU von 1492-28=1464. Vielleicht benötigt der Glasfaseranschluss noch irgendwelche Zusatzdaten im Header? Bin da überfragt :x.

Edit: Hast du auch den Destination-Cache gelöscht?

IPv4:
netsh interface ipv4 delete destinationcache
netsh interface ipv4 show destinationcache interface="Ethernet"


IPv6:
netsh interface ipv6 delete destinationcache
netsh interface ipv6 show destinationcache interface="Ethernet"

[qiller]

...
edit: Noch ein Test[/B]: wenn ich ping -f -l xxxx 192.168.0.1 (xxxx steht für den MTU-Wert) eingebe, fragmentiert er erst ab 1473, also ab 1472 ist es unfragmentiert. Wenn ich aber den anderen Befehl ausführe(Ping google.de -f -l 1464), ist es erst ab 1464 unfragmentiert.

Ja siehe mein letzten Post. Intern hast du ganz normal Ethernet-typisch eine MTU von 1500. Bei Verbindungen ins Internet hast du allerdings eine MTU von 1492. Hier benötigt deine Glasfaserleitung noch irgendwelche Zusatz-Infos, die deinen Header im unter der IP-Schicht liegenden Layer-2-Protokoll (ka, was bei Glasfaser benutzt wird) um 8 Bytes vergrößert.

Mein Kabelanschluss hat übrigens überall hin eine MTU von 1500, sprich ich kann mit ping <Ziel> -f -l 1472 meinen Router wie auch z.B. den Google-Server problemlos anpingen.

[Schnäppchenjäger]

Edit: Hast du auch den Destination-Cache gelöscht?

IPv4:
netsh interface ipv4 delete destinationcache
netsh interface ipv4 show destinationcache interface="Ethernet"

IPv6:
netsh interface ipv6 delete destinationcache
netsh interface ipv6 show destinationcache interface="Ethernet"
Was bringt es mir, den zu löschen?
Ja siehe mein letzten Post. Intern hast du ganz normal Ethernet-typisch eine MTU von 1500. Bei Verbindungen ins Internet hast du allerdings eine MTU von 1492. Hier benötigt deine Glasfaserleitung noch irgendwelche Zusatz-Infos, die deinen Header im unter der IP-Schicht liegenden Layer-2-Protokoll (ka, was bei Glasfaser benutzt wird) um 8 Bytes vergrößert.

Ist mir beim Lesen auch grad aufgefallen, intern über Ethernet ist die MTU immer auf 1500 gesetzt. :biggrin: Man bin ich blöd ;D
Ich glaube, die MTU von Glasfaser ist wohl doch 1492, da es ja auch PPoE ist. Nicht anders als bei den meisten VDSL- und DSL-Anschlüssen.
Habe da wohl das interne Ethernet und den tatsächlichen MTU-Wert verwechselt bei dem Anpingen mit verschiedenen Befehlen.

Ist es etwas schlimmes, wenn der Wert 1500 auf 1492 umgemünzt wird von Ethernet in den Router und dann ins Internet? Man könnte ja den Wert vom Ethernet auch auf 1492 runterbringen, wüsste aber nicht ob das Sinn ergeben würde, zumal LAN standardmäßig auf 1500 belassen wird.

[qiller]

Man braucht da nix mehr rumzufummeln, wenn Path MTU Discovery aktiv ist (bei IPv4 ist das Opt-IN, bei IPv6 Opt-Out). Im Prinzip ist das schon nen Vorteil, weil für jede Verbindung die optimale MTU benutzt werden kann. Man denke da mal an die Jumbo-Frames. Wenn man nen LAN hat, wo alle Komponenten (Quelle, Ziel, Switch) das unterstützen, wärs doch doof, wenn man wegen der Festlegung auf ~1500er MTUs fürs Internet die 9k-MTUs fürs LAN nicht nutzen könnte. Nagut, wird wahrscheinlich erst richtig interessant, wenn sich 5 oder 10Gbit LANs durchsetzen.

Dass die Glasfaser-Anschlüsse der Telekom PPPoE benutzen, wusst ich gar nicht. Das erklärt natürlich die verringerte MTU im Internet.

[xiao didi *]

Dass die Glasfaser-Anschlüsse der Telekom PPPoE benutzen, wusst ich gar nicht.
Ist mir auch neu. Ich vermute, damit sie ihre bestehende Infrastruktur zur Authentifizierung weiter nutzen können.

[Schnäppchenjäger]

(bei IPv4 ist das Opt-IN, bei IPv6 Opt-Out).
Heißt das, dass es bei ipv4 automatisch aktiv ist, oder bei ipv6?
Jumboframes sind bei meinem Netzwerkadapter automatisch ausgestellt, bringen wohl nur im peer2peer LAN was.
Path MTU Discovery müsste nei mir aktiviert sein, kA wo man das nachschaut.

[qiller]

PMTU ist bei IPv6 standardmäßig an, bei IPv4 standardmäßig aus. PMTU auf IPv4-Basis funktioniert im Prinzip wie der Trick oben mit dem ping-Befehl und Setzen des DF-Flags. Bei IPv6 gibts kein DF-Flag mehr, da macht man das über die "packet too big"-Antworten.

Unter Windows ist PMTU schon länger Bestandteil: https://technet.microsoft.com/en-us/library/cc957539.aspx

[Schnäppchenjäger]

hm, es war bei mir deaktiviert denke ich, der Reg key war nicht existent. Habe den mal gesetzt, habe ja nur noch ipv4. Hoffe, das macht nix kaputt^^

[lumines]

Habe den mal gesetzt, habe ja nur noch ipv4. Hoffe, das macht nix kaputt^^

:frown:

Kaputt geht dadurch nichts, aber du tunnelst jetzt eventuell IPv6 über IPv4 mit Teredo, wenn Windows das für manche Dienste benutzt. Mit nativem IPv6 wird Teredo automatisch deaktiviert.

Wenn du natives IPv6 aktiv hättest, würdest du auch davon profitieren, wenn entweder IPv4 oder IPv6 langsamer geroutet werden. Dein OS sollte sich dann im besten Fall das schneller antwortende Protokoll selbst auswählen. Mit Dual-Stack hat man in gewisser Hinsicht eine Art Redundanz. Habe schon öfter gesehen, dass eins von beiden mal seltsam oder anders geroutet wurde. Wenn man sowohl IPv4 als auch IPv6 aktiv hat, merkt man davon selten etwas.

Schneller oder besser wird es jedenfalls nicht, wenn man IPv4-only fährt. Generell wirst du dir deine Performance eher kaputtmachen, wenn du Dinge einstellst, die du nicht ganz verstehst. Am Default gibt es heute nichts wirklich sinnvolles zu "optimieren", wenn man nicht gerade sehr an den Eingeweiden von TCP/IP interessiert ist oder RFCs beim Frühstück liest. Wobei ich jetzt auch nicht wüsste, was man bei Windows überhaupt großartig einstellen sollte. Die ganzen experimentellen Sachen, die bessere Performance versprechen, findet man eher im Linux-Kernel.

Path MTU Discovery müsste nei mir aktiviert sein, kA wo man das nachschaut.

In deinem und den anderen Routern auf dem Weg zum anderen Host. Kann man sicher auch per ICMPv6 irgendwie testen.

Bei IPv6 kannst du einfach davon ausgehen, dass es funktioniert. Dafür ist es viel zu essentiell, als dass jemand ICMPv6 und die wichtigen Codes blockieren würde.

Dass irgendwelche genialen Admins ICMP blockieren war eher noch mit IPv4 so. IPv6 basiert aber ganz stark auf ICMPv6, daher muss man sich damit beschäftigen und kann nicht einfach willkürlich Dinge blocken ohne auch gleichzeitig IPv6 zu verlieren. Deshalb würde ich mir da auch keine Sorgen machen.

Edit: Ich seh gerade in deinem Screenshot im ersten Post, dass der Router wohl gar keine IPv6-Adressen in deinem LAN per DHCPv6 vergibt (Unique Local Unicast: fc00:: ), sondern deine NIC in Windows einfach auf Autoconfig steht (Link Local Unicast: fe80::1). Soweit ich weiß, werden die Autoconfig-IP-Bereiche doch gar nicht ins Internet weitergeroutet, oder schickt Windows die IPv6-Pakete dann trotzdem einfach zum Router und der macht dann ne Art NAT? Wenn nicht, dürfte natives IPv6 beim TE gar nicht funktionieren (sondern höchstens Teredo-Tunnel o.ä.).

Edit2: Ok, hat sich wohl geklärt, der Speedport benutzt einfach den fe80::-Bereich für die Adress-Vergabe. Ka ob das jetzt standardkonform ist.

Hat mit NAT nichts zu tun. Per DHCPv6 verteilt man bei IPv6 auch üblicherweise keine IP-Adressen. Man gibt einfach das Prefix im Netzwerk bekannt und die Geräte generieren dann selbständig ihre Adressen. Das kann man bei IPv6 machen, weil die Chance von Kollisionen im Gegensatz zu den Adressen von IPv4 verschwindend gering ist. IPv6 hat auch Mechanismen, wie es mit eventuellen Kollisionen umgeht. Da muss man sich keine Gedanken machen.

Bei IPv6 passiert das meistens per SLAAC, auch wenn Windows theoretisch Prefixes per DHCPv6 bekommen kann. Schnäppchenjäger hat seine globalen IPv6-Adressen im Screenshot ja auch ausgegraut.

Ist jedenfalls vollkommen in Ordnung, dass man als DNS-Server den Speedport über die Link-Local-Adresse anspricht. Link Local für das Gateway hört sich für mich jetzt auch nicht unlogisch an. Der Provider meines vServers macht das genau so. Es ist eben angenehm simpel und funktioniert. Generell sind die Link-Local-Adressen ein ziemlich unterschätztes Feature von IPv6.

Muss man alles aber auch nicht wissen. Es funktioniert einfach.

[Schnäppchenjäger]

:frown:

Kaputt geht dadurch nichts, aber du tunnelst jetzt eventuell IPv6 über IPv4 mit Teredo, wenn Windows das für manche Dienste benutzt. Mit nativem IPv6 wird Teredo automatisch deaktiviert.Ich habe Teredo und den ganzen Ipv6 Quark doch längst deaktiviert, der kann das doch gar nicht mehr tunneln? :biggrin:

Habe mal folgende Befehle eingegegben um den Staus anzuzeigen:

netsh int tcp show global
netsh interface ipv4 show destinationcache interface="Ethernet"

Raus kam folgendes:

[lumines]

Was heißt Quark? IPv6 ist unser aktuelles Protokoll. IPv4 ist wortwörtlich auf dem Abstellgleis und wird bei neuen Entwicklungen und Standards gar nicht mehr beachtet.

Ich will dir auch nichts vorschreiben, aber es gibt leider haufenweise sehr subtile Gründe, warum man IPv6 heute nicht mehr abschalten will. Du lässt eventuell Performance auf der Strecke. IPv4 wird nicht mehr besser, nur noch schlechter. Das kann durch suboptimales Routing passieren oder andere "softe" Gründe haben. Durch die Adressknappheit bei IPv4 wurden und werden auf allen Seiten immer mehr seltsame Hacks erfunden.

Man kann da leider nicht auf einen großen Punkt zeigen, aber IPv4 und IPv6 werden regelmäßig verglichen und man findet da oft Dinge, die man oft nicht vermuten würde:

Ftoy2tp4kDM

Du musst dich ja nicht einmal für eins von beiden entscheiden. Lass einfach den Default wie er war und freu dich, dass alles optimal funktioniert. Dein OS weiß da tatsächlich sehr viel besser, welches Protokoll wann bevorzugt werden sollte.

[Schnäppchenjäger]

Ich finde es Quark, da die Telekom noch kein natives IPv6 hat, es wird wenn dann eh durch Ipv4 getunnelt. Wenn es denn mal soweit ist, dass man das einschalten kann ohne dass er tunnelt, werde ich es natürlich wieder einschalten.

[lumines]

Das habe ich ja nur ganz am Anfang vermutet, weil die MTU bei dir mit IPv6 geringer als per v4 angezeigt wurde, aber die Telekom fährt sonst eigentlich immer Dual-Stack. Bei dir läuft scheinbar alles über PPPoE, aber PPPoE ist kein IP. PPPoE sitzt unter IP im Netzwerkstack. Das sagt nichts über die Protokolle darüber aus. Theoretisch kann man über PPPoE auch Protokolle benutzen, die gar nicht auf IP basieren.

Und wie gesagt, wenn wird heute vom Provider aus eher IPv4 über IPv6 getunnelt und nicht umgekehrt. Es gibt heute für einen privaten Anwender praktisch kein Szenario, in dem man irgendetwas gewinnt, wenn man v6 deaktiviert. Man kann damit nur Performance und Zuverlässigkeit verlieren.

[Schnäppchenjäger]

Das habe ich ja nur ganz am Anfang vermutet, weil die MTU bei dir mit IPv6 geringer als per v4 angezeigt wurde, aber die Telekom fährt sonst eigentlich immer Dual-Stack.Im Windows Netzwerkbadge unten in der Taskleiste, ja, ich habe auch nicht gerafft, wieso das so ist. Am tatsächlcihen MTU-Wert hat das aber nichts verändert, der ist nach wie vor gleich. Ich war nur zu blöd und habe zuerst den Router angepingt, der ja über Ethernet 1500 aufgebaut ist und danach ins Internet mit 1492 über WAN ;D

Ja, die Telekom hat Dualstack, ich kriege ja auch eine IPv6 Adresse zusätzlicher zu meiner Ipv4 Adreses zugewiesen, nur ist es halt nicht nativ.

[lumines]

Mir ist schon klar, dass die Frau bei der Hotline das behauptet, aber so wirklich glauben kann ich das nicht. Dual-Stack bedeutet eigentlich, dass da nichts gekapselt wird. Würde für die Telekom auch gar keinen Sinn ergeben. Man will ja möglichst wenige IPv4-Adressen benutzen.

Ich mein, ich will das nicht ausschließen, aber das kommt mir schon sehr seltsam vor.

[Schnäppchenjäger]

Mir ist schon klar, dass die Frau bei der Hotline das behauptet, aber so wirklich glauben kann ich das nicht. Dual-Stack bedeutet eigentlich, dass da nichts gekapselt wird. Würde für die Telekom auch gar keinen Sinn ergeben. Man will ja möglichst wenige IPv4-Adressen benutzen.

Ich mein, ich will das nicht ausschließen, aber das kommt mir schon sehr seltsam vor.
Wieso seltsam? Die Infrastruktur ist schon da, es ist aber kein natives Ipv6, natürlich wird da gekapselt. Das IPV6 bohrt sich dann einen Tunnel in das NAT.
Die IPv6-Adrese wird zwar vergeben, "richtig" benutzen kann man sie aber nicht.
Viele schalten das halt einfach aus.

[qiller]

Wenn dein IPv6 gekapselt wäre, hättest du keine 10/10 Punkte in dem Test oben bekommen. Du hast natives IPv6.

Dein Screenshot oben zeigt übrigens sehr schön, dass bei dir PMTU auch für IPv4 aktiv ist, sind neben den vielen 1500er Werten auch ein paar Ziele mit 1492 dabei. Wie schon paarmal erwähnt worden, man muss mittlerweile nix mehr rumfummeln. Kann da lumines nur zustimmen.

Edit: Nur zur Info, ich hab z.B. zum Target "5.153.60.125" ne 1500er MTU, im Gegensatz zu dir. Das ist aber alles vollkommen i.O. so.

[Schnäppchenjäger]

Wenn dein IPv6 gekapselt wäre, hättest du keine 10/10 Punkte in dem Test oben bekommen. Du hast natives IPv6.

Dein Screenshot oben zeigt übrigens sehr schön, dass bei dir PMTU auch für IPv4 aktiv ist, sind neben den vielen 1500er Werten auch ein paar Ziele mit 1492 dabei.
So sollte es ja auch sein oder? Weiß nur nicht, ob das eingeschaltet ist weil ich das nachträglich per Registry hinzugefügt habe oder ob das sowieso von vornherein eingeschaltet war ;D

[PHuV]

Bei meinem 10GBit-Interface steht bei MTU sogar 16334. :tongue: Vermutlich, weil ich manuell auf JumboFrames umgestellt hatte.