IPv4 fragmenterer underveis; IPv6 sender i stedet en melding om for stor pakke

IPv6-feil blir mye oftere lagt på protokollen enn på pakkestørrelsen som forårsaket dem. De to familiene håndterer faktisk en overstor pakke forskjellig, og en tunnel er det som gjør forskjellen viktig. IPv4-rutere kan fragmentere en pakke når reglene tillater det, mens IPv6-rutere ikke skal fragmentere underveis i det hele tatt. IPv6 sier det i stedet til avsenderen, og avsenderen forventes å reagere. Alt som går galt etterpå, følger av om den meldingen kommer frem.

Hva hver familie gjør

Tabellen er mekanismen på fire linjer, og én rad forklarer det meste av forvirringen.

IPv6 har ingen fragmentering underveis og ingen DF-flagg å fjerne, så det er ingenting å falle tilbake på når en pakke er for stor. Avsenderen må få beskjed, og avsenderen må tro på det.

Tunnelen snevrer inn veien i stillhet

En VPN legger til ytre headere, og i det krypterte tilfellet også integritetsdata, før pakken forlater verten. Den indre pakken kan passe i MTU-en til grensesnittet den ser, mens den ytre pakken overskrider grensen til neste ledd, og derfor dukker dette først opp i en tunnel. Senk MTU-en til tunnelgrensesnittet med vilje, eller klem TCP MSS på veien, og skriv ned hvilket tall du valgte og hvorfor.

ESP-overheaden avhenger av modus og algoritmer, så riktig tunnel-MTU er en beregning og ikke en konvensjon. Uansett hva du velger, må det gi plass til en full indre IPv6-pakke på 1280 byte, fordi hvert IPv6-ledd må bære så mye. En tunnel som ikke kan bære 1280 byte med IPv6, er ikke et tuning-problem; det er en brutt vei for den familien. Nettopp den begrensningen forsvinner når en MTU-verdi kopieres fra en installasjon med bare IPv4.

Hvorfor symptomet er et hang

Feilen er ikke en ren feil, og derfor blir den feildiagnostisert. Et TCP-håndtrykk fullføres, små svar kommer inn, og forbindelsen stopper så snart et stort svar eller en stor opplasting begynner, fordi det er de første pakkene som er store nok til å bli forkastet. SSH kobler til og henger deretter på den første store utdataen, og en sides hode lastes mens kroppen aldri blir ferdig.

Hvis ICMPv6-meldingene om for stor pakke filtreres, lærer avsenderen det aldri og prøver om og om igjen med samme størrelse. Det er et svart hull og ikke en treg vei, og signaturen er en gjentakbar størrelsesgrense og ikke tilfeldig tap. Å holde den relevante kontrolltrafikken tillatt er en del av en fungerende IPv6-installasjon, ikke en høflighet.

Ikke slå av meldingene din egen vei er avhengig av, og beskriv deretter resultatet som en IPv6-feil. Det samme argumentet gjelder IPv4-meldingene Fragmentation Needed, som er like upopulære hos brannmurforfattere og like nødvendige.

Mål grensen, og reparer deretter laget

Sjekk i stedet for å gjette: bruk don't-fragment-flagget på IPv4 og faste nyttelaststørrelser på IPv6, og noter hvor svarene stopper. ping -M do -s 1472 og ping -6 -s 1400 er nok til å fastslå problemets form, og tracepath rapporterer den oppdagede vei-MTU-en underveis.

Reparer deretter laget som eier tallet: MTU-en til tunnelgrensesnittet, MSS-klemmen for TCP, eller selve veien. RFC 8200 er referansen for IPv6-regelen, og den er kortere å lese enn hendelsen den forebygger.

Test familien applikasjonen faktisk bruker, fordi et dobbeltstakket navn kan svare på den ene familien og ikke den andre, og en applikasjon kan bytte etter en nettverksendring. Noter adressen du testet, fordi et resultat mot A-posten ikke sier noe om AAAA-posten.

Behandle størrelsesgrensen som bevis

En gjentakbar størrelsesgrense er en av de få nettverksfeilene som reproduseres nøyaktig, ved samme antall byte, fra samme kilde, hver gang. Det gjør den til en gave og ikke et mysterium, og det betyr også at en rettelse kan verifiseres i stedet for å håpes på.

Skriv den oppdagede MTU-en, tunnel-MTU-en du konfigurerte og testen som beviste forskjellen, inn i saken. Den neste personen vil møte den samme aritmetikken på et annet ledd.