IPv4 pirstoo matkalla; IPv6 lähettää sen sijaan viestin liian suuresta paketista

IPv6:n epäonnistumiset laitetaan paljon useammin protokollan syyksi kuin sen aiheuttaneen paketin koon syyksi. Kaksi perhettä käsittelee ylisuuren paketin todella eri tavalla, ja juuri tunneli tekee erosta merkittävän. IPv4-reitittimet saavat pirstoa paketin, kun säännöt sallivat sen, kun taas IPv6-reitittimet eivät saa pirstoa matkalla lainkaan. IPv6 kertoo sen sen sijaan lähettäjälle, ja lähettäjän odotetaan reagoivan. Kaikki, mikä sen jälkeen menee pieleen, seuraa siitä, saapuuko tuo viesti.

Mitä kumpikin perhe tekee

Taulukko on mekanismi neljällä rivillä, ja yksi rivi selittää suurimman osan hämmennystä.

IPv6:ssa ei ole matkalla pirstomista eikä DF-lippua, jota tyhjentää, joten mitään ei ole mihin turvautua, kun paketti on liian suuri. Lähettäjälle on kerrottava, ja lähettäjän on uskottava se.

Tunneli kaventaa polun hiljaa

VPN lisää ulommat otsakkeet, ja salatussa tapauksessa myös eheystiedot, ennen kuin paketti lähtee isännästä. Sisempi paketti voi mahtua näkemäänsä liitännän MTU:hun, kun taas ulompi paketti ylittää seuraavan linkin rajan, ja siksi tämä tulee ensiksi esiin tunnelissa. Laske tunneliliitännän MTU:tä tarkoituksella tai kiristä TCP MSS polulla, ja kirjoita ylös, minkä luvun valitsit ja miksi.

ESP:n ylimääräinen kuorma riippuu tilasta ja algoritmeista, joten oikea tunnelin MTU on laskelma eikä käytäntö. Mitä ikinä valitsetkin, sen on jätettävä tilaa täydelle sisemmälle 1280 tavun IPv6-paketille, koska jokaisen IPv6-linkin on kannettava niin paljon. Tunneli, joka ei kanna 1280 tavua IPv6:ta, ei ole viritysongelma; se on rikkinäinen polku sille perheelle. Juuri tuo rajoitus katoaa, kun MTU-arvo kopioidaan vain IPv4:ää käyttävästä käyttöönotosta.

Miksi oire on jumittuminen

Vika ei ole siisti virhe, ja siksi se diagnosoidaan väärin. TCP-kättely etenee loppuun, pienet vastaukset saapuvat, ja yhteys pysähtyy heti, kun suuri vastaus tai massiivinen lataus alkaa, koska ne ovat ensimmäiset paketit, jotka ovat tarpeeksi suuria pudotettaviksi. SSH yhdistää ja jumittuu sitten ensimmäisessä suuressa tulosteessa, ja sivun otsake latautuu, kun taas runko ei koskaan valmistu.

Jos ICMPv6:n liian suurta pakettia koskevat viestit suodatetaan, lähettäjä ei koskaan opi sitä ja yrittää yhä samaa kokoa. Se on musta aukko eikä hidas polku, ja sen tunnusmerkki on toistettava kokoraja eikä satunnainen häviö. Asianmukaisen ohjausliikenteen salliminen on osa toimivaa IPv6-käyttöönottoa, ei kohteliaisuus.

Älä poista käytöstä viestejä, joista oma polkusi riippuu, ja kuvaile sitten tulosta IPv6-viaksi. Sama argumentti pätee IPv4:n Fragmentation Needed -viesteihin, jotka ovat yhtä epäsuosittuja palomuurien kirjoittajien keskuudessa ja yhtä tarpeellisia.

Mittaa raja ja korjaa sitten kerros

Tarkista sen sijaan että arvaat: käytä don't-fragment-lippua IPv4:ssä ja kiinteitä hyötykuorman kokoja IPv6:ssa, ja kirjaa, mihin vastaukset pysähtyvät. ping -M do -s 1472 ja ping -6 -s 1400 riittävät ongelman muodon selvittämiseen, ja tracepath ilmoittaa havaitun polun MTU:n matkan varrella.

Korjaa sitten se kerros, joka omistaa luvun: tunneliliitännän MTU, TCP:n MSS-kiristys tai itse polku. RFC 8200 on IPv6-säännön viite, ja se on lyhyempi lukea kuin tapaus, jonka se estää.

Testaa perhe, jota sovellus todella käyttää, koska kaksoispinon nimi voi vastata yhdessä perheessä eikä toisessa, ja sovellus voi vaihtaa verkkoympäristön muutoksen jälkeen. Kirjaa testaamasi osoite, koska A-tietueeseen kohdistuva tulos ei kerro mitään AAAA-tietueesta.

Käsittele kokorajaa todisteena

Toistettava kokoraja on yksi harvoista verkkohäiriöistä, joka toistuu täsmälleen, samalla tavumäärällä, samasta lähteestä, joka kerta. Se tekee siitä lahjan eikä arvoituksen, ja tarkoittaa myös, että korjaus voidaan vahvistaa toivomisen sijaan.

Kirjoita tikettiin havaittu MTU, määrittämäsi tunnelin MTU ja testi, joka todisti eron. Seuraava henkilö kohtaa saman aritmetiikan toisella linkillä.