IPv4 fragmenterar på vägen; IPv6 skickar i stället ett meddelande om för stor paket

IPv6-fel skylls mycket oftare på protokollet än på paketstorleken som orsakade dem. De två familjerna hanterar verkligen ett för stort paket olika, och en tunnel är det som gör skillnaden viktig. IPv4-routrar får fragmentera ett paket när reglerna tillåter det, medan IPv6-routrar inte får fragmentera på vägen alls. IPv6 säger det i stället till avsändaren, och avsändaren förväntas reagera. Allt som går fel efteråt följer av om det meddelandet kommer fram.

Vad varje familj gör

Tabellen är mekanismen på fyra rader, och en rad förklarar det mesta av förvirringen.

IPv6 har ingen fragmentering på vägen och ingen DF-flagga att rensa, så det finns inget att falla tillbaka på när ett paket är för stort. Avsändaren måste få veta, och avsändaren måste tro på det.

Tunneln smalnar av vägen i tysthet

En VPN lägger till yttre huvuden, och i det krypterade fallet även integritetsdata, innan paketet lämnar värden. Det inre paketet kan passa i den MTU för gränssnittet som det ser, medan det yttre paketet överskrider gränsen för nästa länk, och därför dyker detta upp först i en tunnel. Sänk tunnelgränssnittets MTU medvetet, eller kläm TCP MSS på vägen, och skriv ned vilket tal du valde och varför.

ESP-overheaden beror på läge och algoritmer, så rätt tunnel-MTU är en beräkning och inte en konvention. Vad du än väljer måste det lämna plats för ett fullt inre IPv6-paket på 1280 byte, eftersom varje IPv6-länk måste bära så mycket. En tunnel som inte kan bära 1280 byte IPv6 är inte ett trimningsproblem; det är en bruten väg för den familjen. Just den begränsningen försvinner när ett MTU-värde kopieras från en installation med bara IPv4.

Varför symtomet är en hängning

Felet är inte ett rent fel, och därför feldiagnostiseras det. Ett TCP-handskakning fullbordas, små svar kommer in, och anslutningen stannar så snart ett stort svar eller en stor uppladdning börjar, eftersom det är de första paketen som är stora nog att kastas. SSH ansluter och hänger sedan på den första stora utdata, och en sidas huvud laddas medan kroppen aldrig blir klar.

Om ICMPv6-meddelandena om för stor paket filtreras lär sig avsändaren aldrig det och fortsätter att försöka med samma storlek. Det är ett svart hål och inte en långsam väg, och dess signatur är en upprepbar storleksgräns och inte slumpmässig förlust. Att tillåta den relevanta kontrolltrafiken är en del av en fungerande IPv6-installation, inte en artighet.

Stäng inte av de meddelanden som din egen väg är beroende av och beskriv sedan resultatet som ett IPv6-fel. Samma argument gäller IPv4:s Fragmentation Needed-meddelanden, som är lika impopulära hos brandväggsförfattare och lika nödvändiga.

Mät gränsen och reparera sedan lagret

Kontrollera i stället för att gissa: använd don't-fragment-flaggan på IPv4 och fasta nyttolaststorlekar på IPv6, och notera var svaren slutar. ping -M do -s 1472 och ping -6 -s 1400 räcker för att fastställa problemets form, och tracepath rapporterar den upptäckta väg-MTU:n längs vägen.

Reparera sedan det lager som äger talet: tunnelgränssnittets MTU, MSS-klämningen för TCP, eller själva vägen. RFC 8200 är referensen för IPv6-regeln, och den är kortare att läsa än incidenten den förebygger.

Testa den familj som applikationen faktiskt använder, eftersom ett dual-stack-namn kan svara på den ena familjen och inte den andra, och en applikation kan byta efter en nätverksändring. Notera adressen du testade, eftersom ett resultat mot A-posten inte säger något om AAAA-posten.

Behandla storleksgränsen som bevis

En upprepbar storleksgräns är ett av de få nätverksfel som reproduceras exakt, vid samma antal byte, från samma källa, varje gång. Det gör den till en gåva och inte ett mysterium, och det betyder också att en rättelse kan verifieras i stället för att hoppas på.

Skriv den upptäckta MTU:n, tunnel-MTU:n du konfigurerade och testet som bevisade skillnaden i ärendet. Nästa person kommer att möta samma aritmetik på en annan länk.