IPv4 fragmentează în tranzit; IPv6 trimite în schimb un mesaj de pachet prea mare
Doar routerele IPv4 pot fragmenta un pachet prea mare. IPv6 așteaptă ca expeditorul să reacționeze la mesajul de pachet prea mare, pe care un tunel sau o regulă ICMP filtrată îl pot rupe.
Eșecurile IPv6 sunt puse pe seama protocolului mult mai des decât pe seama dimensiunii pachetului care le-a provocat. Cele două familii tratează într-adevăr diferit un pachet supradimensionat, iar tunelul este cel care face diferența importantă. Routerele IPv4 pot fragmenta un pachet când regulile permit, în timp ce routerele IPv6 nu trebuie să fragmenteze în tranzit deloc. IPv6 spune asta în schimb expeditorului, iar expeditorul este așteptat să reacționeze. Tot ce merge prost după aceea decurge din dacă acel mesaj ajunge.
Ce face fiecare familie
Tabelul este mecanismul în patru linii, iar o linie explică cea mai mare parte a confuziei.
| Behaviour | IPv4 | IPv6 |
|---|---|---|
| Router fragments an oversized packet | Allowed while DF is clear | Never |
| Signal returned to the sender | ICMP Fragmentation Needed | ICMPv6 Packet Too Big |
| Size that must always work | 68 bytes | 1280 bytes |
| Fragmentation possible | Routers or source | Source only |
IPv6 nu are fragmentare în tranzit și nici un steag DF de șters, așa că nu există nimic pe care să te bazezi când un pachet este prea mare. Expeditorului trebuie să i se spună, iar expeditorul trebuie să creadă.
Tunelul îngustează calea în tăcere
Un VPN adaugă antete exterioare, iar în cazul criptat și date de integritate, înainte ca pachetul să părăsească gazda. Pachetul interior poate încăpea în MTU-ul interfeței pe care îl vede, în timp ce pachetul exterior depășește limita următoarei legături, și de aceea asta apare mai întâi într-un tunel. Coborâți deliberat MTU-ul interfeței tunelului sau strângeți TCP MSS pe cale, și notați ce valoare ați ales și de ce.
Suprasarcina ESP depinde de mod și de algoritmi, așa că MTU-ul corect al tunelului este un calcul, nu o convenție. Orice ați alege, trebuie să lase loc pentru un pachet IPv6 interior complet de 1280 de octeți, pentru că fiecare legătură IPv6 trebuie să transporte atât. Un tunel care nu poate transporta 1280 de octeți de IPv6 nu este o problemă de reglaj; este o cale ruptă pentru acea familie. Exact această constrângere dispare când o valoare de MTU este copiată dintr-o implementare doar cu IPv4.
De ce simptomul este o blocare
Eșecul nu este o eroare curată, și de aceea este diagnosticat greșit. Un handshake TCP se finalizează, răspunsuri mici sosesc, iar conexiunea se blochează imediat ce începe un răspuns mare sau o încărcare masivă, pentru că acelea sunt primele pachete suficient de mari ca să fie aruncate. SSH se conectează și apoi se blochează la prima ieșire mare, iar antetul unei pagini se încarcă în timp ce corpul nu se termină niciodată.
Dacă mesajele ICMPv6 de pachet prea mare sunt filtrate, expeditorul nu află niciodată și reîncearcă mereu aceeași dimensiune. Asta este o gaură neagră, nu o cale lentă, iar semnătura ei este o limită de dimensiune reproductibilă, nu o pierdere aleatorie. Permiterea traficului de control relevant face parte dintr-o implementare IPv6 care funcționează, nu este o curtoazie.
Nu dezactivați mesajele de care depinde propria voastră cale și apoi nu descrieți rezultatul ca o defecțiune IPv6. Același argument se aplică mesajelor Fragmentation Needed din IPv4, la fel de nepopulare la autorii de firewall și la fel de necesare.
Măsurați limita, apoi reparați stratul
Verificați în loc să ghiciți: folosiți steagul don't-fragment pe IPv4 și dimensiuni fixe de încărcare pe IPv6, și notați unde se opresc răspunsurile. ping -M do -s 1472 și ping -6 -s 1400 sunt suficiente pentru a stabili forma problemei, iar tracepath raportează MTU-ul de cale descoperit pe parcurs.
Apoi reparați stratul care deține numărul: MTU-ul interfeței tunelului, strângerea MSS pentru TCP, sau calea însăși. RFC 8200 este referința pentru regula IPv6, și se citește mai repede decât incidentul pe care îl previne.
Testați familia pe care aplicația o folosește de fapt, pentru că un nume cu stivă dublă poate răspunde pe o familie și nu pe cealaltă, iar o aplicație poate comuta după o schimbare de rețea. Notați adresa pe care ați testat-o, pentru că un rezultat față de înregistrarea A nu spune nimic despre înregistrarea AAAA.
Tratați limita de dimensiune ca dovadă
O limită de dimensiune reproductibilă este una dintre puținele defecțiuni de rețea care se reproduc exact, la același număr de octeți, din aceeași sursă, de fiecare dată. Asta o face un cadou și nu un mister, și înseamnă și că o corectare poate fi verificată în loc să fie sperată.
Scrieți în tichet MTU-ul descoperit, MTU-ul tunelului pe care l-ați configurat și testul care a dovedit diferența. Următoarea persoană va întâlni aceeași aritmetică pe altă legătură.