IPv4 fragmenterer undervejs; IPv6 sender i stedet en meddelelse om for stor pakke

IPv6-fejl bliver langt oftere skudt på protokollen end på den pakkestørrelse, der forårsagede dem. De to familier håndterer faktisk en overdimensioneret pakke forskelligt, og en tunnel er det, der gør forskellen vigtig. IPv4-rutere må fragmentere en pakke, når reglerne tillader det, mens IPv6-rutere slet ikke må fragmentere undervejs. IPv6 fortæller det i stedet til afsenderen, og afsenderen forventes at reagere. Alt, hvad der går galt bagefter, følger af, om den meddelelse når frem.

Hvad hver familie gør

Tabellen er mekanismen på fire linjer, og én række forklarer det meste af forvirringen.

IPv6 har ingen fragmentering undervejs og ingen DF-flag at rydde, så der er intet at falde tilbage på, når en pakke er for stor. Afsenderen skal have besked, og afsenderen skal tro på det.

Tunnelen indsnævrer ruten i stilhed

En VPN tilføjer ydre headere, og i det krypterede tilfælde også integritetsdata, før pakken forlader værten. Den indre pakke kan passe til den interface-MTU, den ser, mens den ydre pakke overskrider næste lednings grænse, og derfor dukker det først op i en tunnel. Sænk tunnelinterfacens MTU med vilje, eller klem TCP MSS på ruten, og skriv ned, hvilket tal du valgte og hvorfor.

ESP-overhead afhænger af tilstand og algoritmer, så den rigtige tunnel-MTU er en beregning og ikke en konvention. Uanset hvad du vælger, skal der være plads til en fuld indre IPv6-pakke på 1280 byte, fordi hvert IPv6-led skal kunne bære så meget. En tunnel, der ikke kan bære 1280 byte IPv6, er ikke et tuning-problem; det er en brudt rute for den familie. Netop den begrænsning forsvinder, når en MTU-værdi kopieres fra en implementering, der kun kører IPv4.

Hvorfor symtomet er et hang

Fejlen er ikke en ren fejl, og derfor bliver den fejldiagnosticeret. Et TCP-handshake gennemføres, små svar ankommer, og forbindelsen går i stå, så snart et stort svar eller en stor upload begynder, fordi det er de første pakker, der er store nok til at blive droppet. SSH forbinder og hænger derefter på det første store output, og en sides header indlæses, mens kroppen aldrig bliver færdig.

Hvis ICMPv6-meddelelserne om for stor pakke filtreres, lærer afsenderen det aldrig og bliver ved med at prøve samme størrelse. Det er et sort hul og ikke en langsom rute, og dets signatur er en gentagelig størrelsesgrænse og ikke tilfældigt tab. At holde den relevante kontroltrafik tilladt er en del af en fungerende IPv6-implementering, ikke en høflighed.

Slå ikke de meddelelser fra, som din egen rute afhænger af, og kald derefter resultatet en IPv6-fejl. Det samme argument gælder for IPv4s Fragmentation Needed-meddelelser, som er lige så upopulære hos firewall-forfattere og lige så nødvendige.

Mål grænsen, og ret så laget

Undersøg i stedet for at gætte: brug don't-fragment-flaget på IPv4 og faste nyttelaststørrelser på IPv6, og noter, hvor svar stopper. ping -M do -s 1472 og ping -6 -s 1400 er nok til at fastslå problemets form, og tracepath rapporterer den fundne rute-MTU undervejs.

Ret derefter det lag, der ejer tallet: tunnelinterfacens MTU, MSS-clampen for TCP eller selve ruten. RFC 8200 er referencen for IPv6-reglen, og den er kortere at læse end den hændelse, den forebygger.

Test den familie, applikationen faktisk bruger, fordi et dual-stack-navn kan svare på den ene familie og ikke den anden, og en applikation kan skifte efter en netværksændring. Noter den adresse, du testede, fordi et resultat mod A-recorden intet siger om AAAA-recorden.

Behandl størrelsesgrænsen som bevis

En gentagelig størrelsesgrænse er en af de få netværksfejl, der reproduceres præcist, ved samme byteantal, fra samme kilde, hver gang. Det gør den til en gave og ikke et mysterium, og det betyder også, at en rettelse kan verificeres i stedet for at håbes på.

Skriv den fundne MTU, den konfigurerede tunnel-MTU og den test, der beviste forskellen, i sagen. Den næste person vil møde den samme aritmetik på et andet led.