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 আর পার্থক্য প্রমাণ করা পরীক্ষাটি টিকিটে লিখুন। পরের ব্যক্তি ভিন্ন লিঙ্কে একই হিসাবের মুখোমুখি হবেন।

সম্পর্কিত নিবন্ধ