Oh en ja 1440 is een uitstekende keuze voor de MTU. en ja bij IPV6 worden grotere MTU waardes gewoon gedropt op de interface, en dat stukje ICMP6 logging wordt weer gebruikt voor de MTU Path Discovery

Ik zeg ook niet dat er geen MTU Path Discovery gebruikt moet worden maar ik denk dat dat aan de cliënt zijde ook gewoon gebruikt wordt. Met MTU Path Discovery wordt niet de MTU packetsize bepaalt die je op jouw eigen interface kunt zetten, maar de maximale packetsize (incl. headers) die de software mag verzenden. Op de interfaces mag best een grotere MTU ingesteld staan, het is de MTU Path Discovery waarmee vervolgens bepaald kan worden wat de kleinste van al die MTU's is en dus wat de maximale packetsize (incl. headers) is.

Klopt, alleen als er 1 pad vanaf de server zijde tussen zit die een te lage MTU heeft op de interface werkt het simpelweg gewoon niet omdat alles gedropt wordt in de route tussen server en client.

daar zit voor IPv6 het verschil met IPv4.

IPv6 ondersteunt geen fragmentatie zo als ipv4. IPv6 dropt gewoon met een ICMP6 packet-too-big retour naar de host, maar dan moet die host natuurlijk wel snappen dat ie de MTU omlaag moet brengen. en dat is wat MTU Path Discovery doet.

Maar dan moet ie dat wel doorgestuurd krijgen, en daar gaat het ook vaak mis bij CG-NAT implementaties. dat ICMP verkeer gefilterd of geblokkeerd wordt en dat lijdt tot hetzelfde probleem. Pakketten blijven droppen.

Ook bij IPv4 wordt vrijwel nooit meer packet fragmentation toegestaan.

Maar het is niet de ontvanger die de packetsize bepaalt, dat is de verzender. Dus als Fortigate geen MTU Path Discovery doet maar altijd een payload van 1460 hanteert dan heb je bij IPv6 en een MTU packetsize kleiner dan 1508 de poppetjes aan het dansen terwijl bij IPv4 de minimale MTU packetsize dan 1488 is. Waarschijnlijk is de path MTU packetsize 1500 (internationaal de standaard) en dan gaat dat bij IPv4 dus nog wel goed terwijl dat bij IPv6 leidt tot fragmentatie en dus tot het droppen van de communicatie.

Vandaar ook dat er vaak een maximale payload van 1452 gehanteerd wordt voor VPN verbindingen.

klopt en daarom gaat alles wat boven die 1500 komt ook fout op apn “internet” want dat dropt gewoon. 

dit komt uit een NAT-implementatie of firewall die een ICMP message 'packet too big' van een host upstream niet doorlaat. Uiteindelijk is het dit ICMP message die niet terugkomt bij een host dat PMTUD verbreekt.

en daarom is CG-NAT een waardeloze oplossing voor een gebrek aan IPv4 adressen. het is zo goed als de beheerder. Feitelijk moeten we IPv4 skippen en over naar dedicated IPv6, Dan zijn we volledig van NAT implementaties af. maar dat is een utopie

Terecht voor netwerken waarop geen packet fragmentation toegestaan wordt en er door de verzender toch een groter packet gestuurd wordt. Dan moet je toch echt bij de verzender zijn, niet bij de ontvanger of een partij op de route naar de ontvanger.

Heb jij kunnen constateren dat dat het geval is?

Je gaf zelf aan dat die Fortigate geen MTU Path Discovery ondersteunt. Die zet dus blijkbaar zelf de te gebruiken MTU packetsize en gebruikt geen MTU Packet Discovery. Dan valt er ook weinig te droppen door een CGNAT.

Maar goed, op het IPv6-only netwerk van KPN is helemaal geen sprake van Carrier-Grade natting en op het IPv4 netwerk van Odido (met CGNAT) heeft @iPhone12Dns geen problemen dus hoeven we verder geen aandacht te besteden aan CGNAT.

Nog steeds kunnen pakketten droppen door verkeerde configuratie van dit IPv6 Only deel

ER VAN UITGAANDE DAT DE VPN OOK DAADWERKELIJK OP IPv6 LOOPT

Maar als er een interface is met een te lage limiet (wat de 1500 MTU als grens verklaart) of ICMP filtering aan staat is het gelazer in de glazen. we lopen nog steeds door een APN heen met settings van KPN er in en door netwerk interfaces en firewalls van KPN. of firmware/software van masten. al deze componenten kunnen de boosdoener zijn

MTU Packet Discovery is ZEER belangrijk voor IPv6 en dit moet gewoon gaan functioneren conform de standaard. 

MTU Path Discovery hoeft enkel door de verzender gedaan te worden en door geen enkele andere server op de route. Het is immers de verzender die moet bepalen hoe groot het pakketje mag zijn dat hij wil versturen.

Ik weet dus niet wat je nu wilt zeggen met dat MTU Path Discovery aan moet staan.

En een MTU van 1500 bytes is wereldwijd de standaard voor de MTU packetsize op Ethernet. Dat is dus niet een te lage limiet maar de standaard limiet en daar is dus niets mis mee.

Ik denk ook dat dat het geval zal zijn op de netwerken van KPN, anders zouden die Android telefoons ook geen VPN verbinding op kunnen zetten en dat is dus niet het geval, die werken immers prima via het IPv6-only netwerk van KPN.

MITS de ICMP melding terug komt ja, anders werkt MTU Path Discovery niet

en 1500 MTU is voor ipv4 de standaard.  Niet voor IPv6 daar is alleen een MINIMUM van 1280 voor. en 1500 wordt als algemeen aangehouden aan de client kant maar dat is meer legacy. in feite is daar geen waarde nodig aangezien de server leidend is

overigens kan je met een MTU van 1500 nooit over de 7 Gbit heen komen qua snelheid

Dat zal ook het geval zijn. Nogmaals, met een Android telefoon heeft @iPhone12Dns geen enkel probleem om via hetzelfde IPv6-only netwerk van KPN een VPN verbinding op te zetten. Dan moeten we dus niet de oorzaak ergens op het netwerk gaan zoeken, dat is immers voor die iPhone en die Android telefoon precies hetzelfde netwerk.

nou ja als in de iphone geen max MTU staat en deze vertrouwt op MTU Path Discovery zo als de niet werkende android toestellen en de interfaces van KPN gelimiteerd zijn op 1500 is dat het probleem binnen het netwerk

Overigens is het 100% zeker dat KPN die ICMP6 drops af filtert naar de server toe.

Daar geloof ik helemaal niets van.

Ik ben benieuwd hoe je dat met 100% zekerheid hebt kunnen constateren.

jij gelooft nooit ergens wat van.
maar heel simpel als je zowel logt op client als server en die vergelijkt krijg je een heel concreet beeld.

Wat voor een tools heb je gebruikt om dat aan beide zijden te loggen?

Wat meet je dan aan de cliënt zijde en wat meet je aan de server zijde t.a.v. "path MTU discovery"?

aan beide kanten heb ik gelogged met wireshark, de ICMP6 verzonden door de client naar de server en vice versa komen niet aan. een verbinding komt ook niet tot stand omdat het verzoek gedropt wordt. er zit dus een icmp verkeer filter tussen

Waar komt die ICMPv6 t.a.v. die path MTU discovery niet aan?

Niet op de server?

Wat krijgt de cliënt dan voor een response?

En Wireshark op een Android telefoon, welke app gebruik je daarvoor?

Tools zat voor Android. Pcap remote bijvoorbeeld.

Welke tools heb je dan gebruikt want blijkbaar was het toch niet Wireshark.

Daarnaast hoop ik dat je ook antwoord hebt op mijn andere vragen.

Ik heb helemaal geen zin om uit te leggen welke tools ik gebruikt heb en hoe ik exact getest heb. Simpelweg omdat jij niet begrijpt dat je ook gewoon je usb kabel in je telefoon kan stoppen en hem aan je laptop kan hangen en zo je verbinding kan delen. Of via wifi 

In alle gevallen is de uitkomst hetzelfde en dat is waar het om gaat

En antwoorden op mijn andere vragen zullen we ook wel niet gaan krijgen.

Ik ben er absoluut niet van overtuigd dat het KPN netwerk ICMPv6 verkeer zou droppen, sterker nog ik maak me sterk dat ICMPv6 gewoon netjes ondersteund wordt, ook voor path MTU discovery immers op de Android telefoon van ​@iPhone12Dns is het prima mogelijk via datzelfde netwerk een verbinding op te zetten.

Het heeft te maken met je toon. Het is allemaal te betweterig. Bovendien is het iets wat met td van kpn opgepakt moet worden en die laten het volledig af weten hier.

Besef wel dat dit een kpn issue is en alleen bestaat bij kpn. MTU begrenzen lost het op. How en waarom is niet voor de consument maar voor de netwerk mannen. En al typen we het hier volledig uit, dan nog doet men er niets mee. Want de klant is volgens kpn dom en achterlijk. 

En dat betekent dus dat iemand niet goed om gaat met path MTU discovery.

Nu zijn we beide op zoek naar de oorzaak daarvan. Ik hoop ook dat we met die gedachte verder zouden kunnen. 

Je zegt dat dat komt doordat ICMPv6 berichten uitgefiltered/geblokkeerd worden door het KPN netwerk. Ik trek dat echter sterk in twijfel immers als dat zo zou zijn dan zou ik hetzelfde probleem ook verwachten als een Android toestel gebruikt wordt maar, zoals je hebt kunnen lezen, lijkt dat niet het geval immers ​@iPhone12Dns heeft geen problemen met zijn Android telefoon, enkel met zijn iPhone.

Vandaar dat ik zo benieuwd ben naar wat je dan gemeten hebt want ik verwacht dat als jouw toestel netjes path MTU discovery geïnitieerd heeft dat deze een bericht heeft ontvangen dat de MTU size exceeded is met daarbij de maximaal toegestane MTU size en dat hij daarmee weer verder is gegaan met de path MTU discovery net zolang totdat hij de target host bereikt heeft.

En als het zo zou zijn de de cliënt helemaal geen antwoord krijgt dan zou dat mijns inziens dus ook fout moeten lopen op een Android toestel maar dat lijkt dus niet het geval te zijn.

En als jouw toestel/software helemaal geen path MTU discovery uit zou voeren dan is het handmatig klein genoeg maken van de MTU size inderdaad een "oplossing" maar dan ligt de oorzaak dus bij het toestel of de gebruikte software (Forticlient) en kan KPN hier niets in betekenen.

Nee ik zeg dat er ergens op een interface binnen kpn (l2 of l3) een te laag MTU staat ingesteld. Dat Path Discovery niet werkt is meer een issue die laat zien dat men niet op de hoogte is van de actuele standaard. Maar ook precies datgene wat had kunnen voorkomen dat het breekt zo als nu

​@iPhone12Dns Aangezien dat je via android en niet via ios een VPN verbinding kan opzetten, vermoed ik dat het probleem ligt bij IOS forticlient, het ondersteunt geen dual stack IPv4/IPv6. Je kan een IPv6 adres gebruiken of een IPv4 met een DNS64 server, b.v. Google 2001:4860:4860::6464. KPN mobiel is een IPv6 only netwerk en je zal probleem krijgen met verbinding tot IPv4 only adres.

Dus je zei niet dat KPN ICMPv6 filtert of blokkeert?

Francoix schreef::

 

Dat zou dan overigens een MTU lager dan 1280 moeten zijn immers alles boven 1280 is correct en een path MTU discovery zou natuurlijk netjes moeten constateren dat die lage MTU ingesteld is zodat de in de communicatie te gebruiken MTU size op die waarde wordt ingesteld. Dat is immers de functie van path MTU discovery ... de maximale MTU size bepalen die voor de communicatie gebruikt kan worden.

En als het een MTU lager dan 1280 zou zijn dan zou ook die Android telefoon daar niet mee overweg moeten kunnen en dus tegen hetzelfde probleem aan moeten lopen.

Francoix schreef:

Dat Path Discovery niet werkt is meer een issue die laat zien dat men niet op de hoogte is van de actuele standaard. Maar ook precies datgene wat had kunnen voorkomen dat het breekt zo als nu

Maar path MTU discovery is iets dat geïnitieerd wordt door de cliënt (telefoon), niet door een component in het netwerk. De hops in het netwerk hoeven enkel te reageren op een path MTU discovery en dat zullen ze vast ook doen immers anders zou je op die Android telefoon ook deze problematiek moeten ervaren en dat is dus niet het geval.