IPv4 fragmenteert onderweg; IPv6 stuurt in plaats daarvan een melding dat het pakket te groot is

IPv6-storingen worden veel vaker aan het protocol geweten dan aan de pakketgrootte die ze veroorzaakte. De twee families behandelen een te groot pakket echt verschillend, en een tunnel is wat dat verschil belangrijk maakt. IPv4-routers mogen een pakket fragmenteren wanneer de regels dat toestaan, terwijl IPv6-routers onderweg helemaal niet mogen fragmenteren. IPv6 zegt het in plaats daarvan tegen de afzender, en van de afzender wordt verwacht dat hij reageert. Alles wat daarna misgaat, volgt uit of die melding aankomt.

Wat elke familie doet

De tabel is het mechanisme in vier regels, en één rij verklaart het grootste deel van de verwarring.

IPv6 heeft geen fragmentatie onderweg en geen DF-vlag om te wissen, dus er is niets om op terug te vallen als een pakket te groot is. De afzender moet het weten, en de afzender moet het geloven.

De tunnel vernauwt het pad stil

Een VPN voegt buitenste headers toe, en in het versleutelde geval ook integriteitsgegevens, voordat het pakket de host verlaat. Het binnenste pakket kan in de interface-MTU passen die het ziet, terwijl het buitenste pakket de limiet van de volgende schakel overschrijdt, en daarom komt dit eerst in een tunnel naar boven. Verlaag de MTU van de tunnelinterface bewust, of klem de TCP MSS op het pad, en schrijf op welke waarde je koos en waarom.

De ESP-overhead hangt af van de modus en de algoritmen, dus de juiste tunnel-MTU is een berekening en geen conventie. Wat je ook kiest, het moet ruimte laten voor een volledig binnenste IPv6-pakket van 1280 byte, omdat elke IPv6-schakel dat moet kunnen dragen. Een tunnel die 1280 byte IPv6 niet kan dragen, is geen afstemmingsprobleem; het is een kapot pad voor die familie. Precies die beperking verdwijnt wanneer een MTU-waarde wordt gekopieerd uit een implementatie met alleen IPv4.

Waarom het symptoom een hang is

De storing is geen schone fout, en daarom wordt ze verkeerd gediagnosticeerd. Een TCP-handshake loopt af, kleine antwoorden komen aan, en de verbinding stokt zodra een groot antwoord of een grote upload begint, omdat dat de eerste pakketten zijn die groot genoeg zijn om te worden weggegooid. SSH verbindt en hangt dan bij de eerste grote uitvoer, en de kop van een pagina laadt terwijl de body nooit klaarkomt.

Als de ICMPv6-meldingen over een te groot pakket worden gefilterd, leert de afzender het nooit en blijft hij dezelfde grootte proberen. Dat is een zwart gat en geen traag pad, en het kenmerk is een herhaalbare groottelimiet en geen toevallig verlies. De relevante controletrafiek toestaan hoort bij een werkende IPv6-implementatie, het is geen beleefdheid.

Schakel de meldingen waarvan je eigen pad afhangt niet uit en beschrijf het resultaat daarna niet als een IPv6-storing. Hetzelfde argument geldt voor de Fragmentation Needed-meldingen van IPv4, die bij firewallauteurs even impopulair en even noodzakelijk zijn.

Meet de grens en repareer dan de laag

Controleer in plaats van te gokken: gebruik de don't-fragment-vlag op IPv4 en vaste payloadgroottes op IPv6, en noteer waar de antwoorden stoppen. ping -M do -s 1472 en ping -6 -s 1400 zijn genoeg om de vorm van het probleem vast te stellen, en tracepath meldt onderweg de gevonden pad-MTU.

Repareer daarna de laag die het nummer bezit: de MTU van de tunnelinterface, de MSS-clamp voor TCP, of het pad zelf. RFC 8200 is de referentie voor de IPv6-regel, en die leest korter dan het incident dat hij voorkomt.

Test de familie die de toepassing echt gebruikt, want een dual-stacknaam kan op de ene familie antwoorden en op de andere niet, en een toepassing kan na een netwerkwijziging overschakelen. Noteer het adres dat je testte, want een resultaat tegen het A-record zegt niets over het AAAA-record.

Behandel de groottelimiet als bewijs

Een herhaalbare groottelimiet is een van de weinige netwerkstoringen die zich exact reproduceert, bij hetzelfde aantal bytes, van dezelfde bron, elke keer. Dat maakt hem een geschenk en geen raadsel, en het betekent ook dat een oplossing kan worden geverifieerd in plaats van gehoopt.

Schrijf de gevonden MTU, de geconfigureerde tunnel-MTU en de test die het verschil bewees in het ticket. De volgende persoon komt dezelfde rekenkunde tegen op een andere schakel.