Naghahati ang IPv4 sa paglalakbay; nagpapadala ang IPv6 ng mensaheng masyadong malaki ang packet sa halip

Ang mga pagkabigo ng IPv6 ay mas madalas na isinisisi sa protocol kaysa sa laki ng packet na naging dahilan nito. Tunay na magkaiba ang pagtrato ng dalawang pamilya sa masyadong malaking packet, at ang tunnel ang nagpapahalaga sa pagkakaibang iyon. Maaaring hatiin ng mga router ng IPv4 ang packet kapag pinapayagan ng mga patakaran, samantalang hindi dapat hatiin ng mga router ng IPv6 sa paglalakbay. Sinasabi ito ng IPv6 sa nagpadala sa halip, at inaasahang tutugon ang nagpadala. Lahat ng nagiging mali pagkatapos ay nakasalalay sa kung dumarating ang mensaheng iyon.

Ano ang ginagawa ng bawat pamilya

Ang talahanayan ang mekanismo sa apat na linya, at isang hilera ang nagpapaliwanag ng karamihan sa kalituhan.

Walang paghati sa paglalakbay ang IPv6 at walang DF flag na lilinisin, kaya wala nang maaaring sandigan kapag masyadong malaki ang packet. Kailangang sabihin sa nagpadala, at kailangang maniwala ang nagpadala.

Tahimik na pinapaliit ng tunnel ang landas

Nagdadagdag ang VPN ng mga panlabas na header, at sa naka-encrypt na kaso pati data ng integridad, bago umalis ang packet sa host. Maaaring kasya ang panloob na packet sa MTU ng interface na nakikita nito habang lumalampas ang panlabas na packet sa hangganan ng susunod na link, at iyon ang dahilan kung bakit ito unang lumilitaw sa isang tunnel. Sadyang babaan ang MTU ng interface ng tunnel, o higpitan ang TCP MSS sa landas, at isulat kung aling numero ang pinili mo at bakit.

Nakasalalay ang overhead ng ESP sa mode at mga algorithm, kaya ang tamang MTU ng tunnel ay kalkulasyon at hindi kaugalian. Anuman ang piliin mo, kailangan nitong mag-iwan ng puwang para sa buong panloob na packet ng IPv6 na 1280 bytes, dahil kailangang magdala ng ganoon ang bawat link ng IPv6. Ang tunnel na hindi makapagdala ng 1280 bytes ng IPv6 ay hindi problema sa tuning; ito ay sirang landas para sa pamilyang iyon. Ang hadlang na iyon ang nawawala kapag ang halaga ng MTU ay kinopya mula sa deployment na IPv4 lamang.

Bakit ang sintomas ay parang paghinto

Ang pagkabigo ay hindi malinis na error, at kaya mali ang diagnosis. Natatapos ang TCP handshake, dumarating ang maliliit na tugon, at humihinto ang koneksyon kapag nagsimula ang malaking tugon o malaking upload, dahil iyon ang mga unang packet na sapat ang laki para itapon. Kumokonekta ang SSH at pagkatapos ay humihinto sa unang malaking output, at naglo-load ang header ng pahina habang hindi natatapos ang katawan.

Kung ang mga mensaheng masyadong malaki ang packet ng ICMPv6 ay sinasala, hindi malalaman ng nagpadala at paulit-ulit na susubukan ang parehong laki. Iyon ay itim na butas at hindi mabagal na landas, at ang lagda nito ay paulit-ulit na hangganan ng laki at hindi random na pagkawala. Ang pagpayag sa kaugnay na control traffic ay bahagi ng gumaganang deployment ng IPv6, hindi kagandahang-loob.

Huwag patayin ang mga mensaheng umaasa ang sarili mong landas sa mga iyon at pagkatapos ay ilarawan ang resulta bilang depekto ng IPv6. Ang parehong argumento ay naaangkop sa mga mensaheng Fragmentation Needed ng IPv4, na kasing-hindi-popular sa mga may-akda ng firewall at kasing-kailangan.

Sukatin ang hangganan, pagkatapos ay ayusin ang layer

Tiyakin sa halip na hulaan: gamitin ang don't-fragment flag sa IPv4 at mga fixed na laki ng payload sa IPv6, at itala kung saan tumitigil ang mga tugon. ping -M do -s 1472 at ping -6 -s 1400 ay sapat upang itatag ang hugis ng problema, at tracepath ay nag-uulat ng natuklasang path MTU sa daan.

Pagkatapos ay ayusin ang layer na nagmamay-ari ng numero: ang MTU ng interface ng tunnel, ang paghigpit ng MSS para sa TCP, o ang landas mismo. Ang RFC 8200 ang sanggunian para sa tuntunin ng IPv6, at mas maikling basahin kaysa sa insidenteng pinipigilan nito.

Subukan ang pamilyang aktwal na ginagamit ng application, dahil ang dual-stack na pangalan ay maaaring tumugon sa isang pamilya at hindi sa isa, at ang application ay maaaring lumipat pagkatapos ng pagbabago sa network. Itala ang address na sinubukan mo, dahil ang resulta laban sa A record ay walang sinasabi tungkol sa AAAA record.

Ituring ang hangganan ng laki bilang ebidensya

Ang paulit-ulit na hangganan ng laki ay isa sa iilang mga depekto ng network na eksaktong nagpaparami, sa parehong bilang ng bytes, mula sa parehong pinagmulan, sa bawat pagkakataon. Ginagawa nitong regalo at hindi palaisipan, at nangangahulugan din itong maaaring i-verify ang pagwawasto sa halip na asahan.

Isulat sa ticket ang natuklasang MTU, ang MTU ng tunnel na na-configure mo at ang test na nagpatunay ng pagkakaiba. Ang susunod na tao ay makakatagpo ng parehong aritmetika sa ibang link.