IPv6ની નિષ્ફળતાઓને પ્રોટોકોલ પર વધુ વાર દોષ આપવામાં આવે છે, જે પૅકેટના કદ પર આપવો જોઈએ જે તેમને કારણભૂત બનાવે છે. બંને કુટુંબો ખરેખર વધુ પડતા મોટા પૅકેટ સાથે અલગ રીતે વર્તે છે, અને ટનલ તે છે જે આ તફાવતને મહત્ત્વનો બનાવે છે. IPv4 રાઉટર્સ નિયમો પરવાનગી આપે ત્યારે પૅકેટને ફ્રેક્મેન્ટ કરી શકે છે, જ્યારે IPv6 રાઉટર્સ ટ્રાન્ઝિટમાં જરાય ફ્રેક્મેન્ટ કરી શકતા નથી. IPv6 તેના બદલે મોકલનારને કહે છે, અને મોકલનાર પ્રતિક્રિયા આપશે એવી અપેક્ષા રાખવામાં આવે છે. પછી જે કંઈ ખોટું જાય છે તે એ સંદેશ પહોંચે છે કે નહીં તેના પરથી આવે છે.

દરેક કુટુંબ શું કરે છે

કોષ્ટક ચાર લાઇનમાં કાર્યવિધિ છે, અને એક પંક્તિ મોટાભાગની ગૂંચવણ સમજાવે છે.

BehaviourIPv4IPv6
Router fragments an oversized packetAllowed while DF is clearNever
Signal returned to the senderICMP Fragmentation NeededICMPv6 Packet Too Big
Size that must always work68 bytes1280 bytes
Fragmentation possibleRouters or sourceSource only

IPv6માં ટ્રાન્ઝિટ ફ્રેક્મેન્ટેશન નથી અને સાફ કરવા માટે DF ફ્લૅગ પણ નથી, તેથી પૅકેટ ખૂબ મોટું હોય ત્યારે પાછા જવા માટે કંઈ નથી. મોકલનારને કહેવું પડે છે, અને મોકલનારે તે માનવું પડે છે.

ટનલ માર્ગને શાંતિથી સાંકડો કરે છે

VPN પૅકેટ હોસ્ટ છોડે તે પહેલાં બાહ્ય હેડર ઉમેરે છે, અને એન્ક્રિપ્ટેડ કિસ્સામાં ઇન્ટિગ્રિટી ડેટા પણ ઉમેરે છે. અંદરનું પૅકેટ જે ઇન્ટરફેસ MTU જુએ છે તેમાં ફિટ થઈ શકે છે, જ્યારે બહારનું પૅકેટ આગલી કડીની મર્યાદા વટાવે છે, અને તેથી જ આ પહેલાં ટનલમાં દેખાય છે. ટનલ ઇન્ટરફેસનું MTU જાણી જોઈને ઘટાડો, અથવા માર્ગ પર TCP MSS ક્લૅમ્પ કરો, અને તમે કઈ સંખ્યા પસંદ કરી અને કેમ તે લખો.

ESPનો ઓવરહેડ મોડ અને અલ્ગોરિધમ પર આધાર રાખે છે, તેથી યોગ્ય ટનલ MTU ગણતરી છે, રૂઢિ નહીં. તમે શું પણ પસંદ કરો, તેણે 1280 બાઇટના પૂરા અંદરના IPv6 પૅકેટ માટે જગ્યા છોડવી જોઈએ, કારણ કે દરેક IPv6 કડીએ તેટલું વહન કરવું પડે છે. જે ટનલ 1280 બાઇટ IPv6 વહન કરી શકતી નથી તે ટ્યુનિંગની સમસ્યા નથી; તે તે કુટુંબ માટે તૂટેલો માર્ગ છે. ફક્ત IPv4 આધારિત ડિપ્લોયમેન્ટમાંથી MTU મૂલ્ય કૉપી કરવામાં આવે ત્યારે એ જ મર્યાદા અદૃશ્ય થાય છે.

લક્ષણ અટકી જવા જેવું કેમ લાગે છે

નિષ્ફળતા સ્વચ્છ ભૂલ નથી, અને તેથી જ તેનું ખોટું નિદાન થાય છે. TCP હેન્ડશેક પૂરો થાય છે, નાના પ્રતિભાવો આવે છે, અને મોટો પ્રતિભાવ કે મોટું અપલોડ શરૂ થતાં જ કનેક્શન અટકી જાય છે, કારણ કે તે ફેંકી દેવા માટે પૂરતા મોટા પ્રથમ પૅકેટ છે. SSH જોડાય છે અને પછી પ્રથમ મોટા આઉટપુટ પર અટકી જાય છે, અને પૃષ્ઠનું હેડર લોડ થાય છે જ્યારે બોડી ક્યારેય પૂર્ણ થતું નથી.

જો ICMPv6ના પૅકેટ ખૂબ મોટું સંદેશા ફિલ્ટર થાય, તો મોકલનારને ક્યારેય ખબર પડતી નથી અને એ જ કદ ફરી ફરી પ્રયત્ન કરે છે. તે કાળું કૂવો છે, ધીમો માર્ગ નહીં, અને તેની ઓળખ પુનરાવર્તિત કદ-સીમા છે, અવ્યવસ્થિત નુકસાન નહીં. સંબંધિત કંટ્રોલ ટ્રાફિકને મંજૂર રાખવો કાર્યક્ષમ IPv6 ડિપ્લોયમેન્ટનો ભાગ છે, ઉપકાર નહીં.

તમારો પોતાનો માર્ગ જે સંદેશાઓ પર આધાર રાખે છે તે બંધ કરો અને પછી પરિણામને IPv6ની ખામી કહો એમ ન કરો. એ જ દલીલ IPv4ના Fragmentation Needed સંદેશાઓને લાગુ પડે છે, જે ફાયરવૉલ લેખકોમાં સમાન અપ્રિય અને સમાન આવશ્યક છે.

સીમા માપો, પછી સ્તર સુધારો

અનુમાન કરવાને બદલે ચકાસો: IPv4 પર don't-fragment ફ્લૅગ અને IPv6 પર નિશ્ચિત પેલોડ કદ વાપરો, અને પ્રતિભાવો ક્યાં અટકે છે તે નોંધો. ping -M do -s 1472 અને ping -6 -s 1400 સમસ્યાનું સ્વરૂપ નક્કી કરવા માટે પૂરતા છે, અને tracepath રસ્તામાં શોધાયેલ માર્ગ MTU જણાવે છે.

પછી જે સ્તર સંખ્યાનો માલિક છે તે સુધારો: ટનલ ઇન્ટરફેસનું MTU, TCP માટે MSS ક્લૅમ્પ, અથવા માર્ગ પોતે. IPv6 નિયમ માટે RFC 8200 સંદર્ભ છે, અને તે જે ઘટના અટકાવે છે તેના કરતાં ટૂંકું વાંચન છે.

એ કુટુંબનું પરીક્ષણ કરો જે એપ્લિકેશન ખરેખર વાપરે છે, કારણ કે ડ્યુઅલ-સ્ટૅક નામ એક કુટુંબમાં જવાબ આપી શકે છે અને બીજામાં નહીં, અને નેટવર્ક ફેરફાર પછી એપ્લિકેશન બદલાઈ શકે છે. તમે પરીક્ષણ કરેલું સરનામું નોંધો, કારણ કે A રેકોર્ડ સામેનું પરિણામ AAAA રેકોર્ડ વિશે કંઈ કહેતું નથી.

કદ-સીમાને પુરાવા તરીકે લો

પુનરાવર્તિત કદ-સીમા એ થોડી નેટવર્ક ખામીઓમાંની એક છે જે દર વખતે એ જ બાઇટ સંખ્યામાં, એ જ સ્રોતથી ચોક્કસ પુનરુત્પાદન થાય છે. એ તેને રહસ્ય નહીં, ભેટ બનાવે છે, અને એનો અર્થ પણ છે કે સુધારો આશા રાખવાને બદલે ચકાસી શકાય છે.

શોધાયેલ MTU, તમે કૉન્ફિગર કરેલ ટનલ MTU અને તફાવત સાબિત કરનાર પરીક્ષણ ટિકિટમાં લખો. આગલી વ્યક્તિ બીજી કડી પર એ જ ગણિત મળશે.

સંબંધિત લેખો