IPv4 راستے میں ٹکڑے کرتا ہے؛ IPv6 اس کے بجائے بہت بڑے پیکٹ کا پیغام بھیجتا ہے

IPv6 کی ناکامیوں کا الزام پروٹوکول پر زیادہ لگایا جاتا ہے، اُس پیکٹ کے حجم پر کم جو اُن کا سبب بنا۔ دونوں خاندان واقعی حد سے بڑے پیکٹ کو مختلف طریقے سے نبٹاتے ہیں، اور سرنگ ہی وہ چیز ہے جو اس فرق کو اہم بناتی ہے۔ IPv4 روٹر قواعد کی اجازت پر پیکٹ کے ٹکڑے کر سکتے ہیں، جبکہ IPv6 روٹر راستے میں بالکل ٹکڑے نہیں کر سکتے۔ IPv6 اس کے بجائے بھیجنے والے کو بتاتا ہے، اور بھیجنے والے سے ردِعمل کی توقع کی جاتی ہے۔ اس کے بعد جو کچھ غلط ہوتا ہے وہ اسی پر منحصر ہے کہ وہ پیغام پہنچتا ہے یا نہیں۔

ہر خاندان کیا کرتا ہے

جدول چار سطروں میں طریقہ کار ہے، اور ایک سطر زیادہ تر الجھن کی وضاحت کرتی ہے۔

IPv6 میں راستے میں ٹکڑے کرنا نہیں ہے اور صاف کرنے کے لیے کوئی DF پرچم بھی نہیں، اس لیے پیکٹ حد سے بڑا ہونے پر سہارا لینے کے لیے کچھ نہیں۔ بھیجنے والے کو بتانا پڑتا ہے، اور بھیجنے والے کو یہ ماننا پڑتا ہے۔

سرنگ راستہ خاموشی سے تنگ کرتی ہے

VPN پیکٹ کے میزبان چھوڑنے سے پہلے بیرونی ہیڈر شامل کرتا ہے، اور خفیہ حالت میں سالمیت کا ڈیٹا بھی شامل کرتا ہے۔ اندرونی پیکٹ اُس انٹرفیس MTU میں سما سکتا ہے جو وہ دیکھتا ہے، جبکہ بیرونی پیکٹ اگلی کڑی کی حد سے بڑھ جاتا ہے، اور اسی لیے یہ پہلے سرنگ میں ظاہر ہوتا ہے۔ سرنگ انٹرفیس کا MTU جان بوجھ کر کم کریں، یا راستے میں TCP MSS کو کس دیں، اور لکھیں کہ آپ نے کون سا عدد چنا اور کیوں۔

ESP کا اضافی بوجھ موڈ اور الخوارزم پر منحصر ہے، اس لیے درست سرنگ MTU ایک حساب ہے، روایت نہیں۔ آپ جو بھی چنیں، اسے پورے 1280 بائٹ کے اندرونی IPv6 پیکٹ کے لیے جگہ چھوڑنی چاہیے، کیونکہ ہر IPv6 کڑی کو اتنا ہی اٹھانا ہے۔ جو سرنگ 1280 بائٹ IPv6 نہیں اٹھا سکتی وہ ٹیوننگ کا مسئلہ نہیں؛ وہ اُس خاندان کے لیے ٹوٹا ہوا راستہ ہے۔ یہی حد اُس وقت ختم ہوتی ہے جب MTU کی قدر کسی صرف IPv4 والی تعیناتی سے نقل کی جائے۔

علامت اٹکاؤ کی طرح کیوں دکھتی ہے

ناکامی کوئی صاف غلطی نہیں ہے، اور اسی لیے اس کی غلط تشخیص ہوتی ہے۔ 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 اور وہ جانچ جو فرق ثابت کرے، ٹکٹ میں لکھیں۔ اگلا شخص کسی دوسری کڑی پر وہی حساب پائے گا۔